BPM Chile Day 2011 - Informe BPM&SOA

GRUPO DE ESTUDIO BPM – SOA

Elaborado por: Ángel Yaulilahua (angel.yaulilahua@gmail.com)

ENFOQUE:

 Todas las respuestas a las preguntas están orientadas a lograr el objetivo de encaminar a una
organización hacia la implementación de BPM y SOA.

 Si bien se puede implementar BPM sin usar herramientas especializadas (gestión de procesos
únicamente desde la perspectiva de negocio) en este trabajo se abordará el enfoque de BPM
que aborda tanto la perspectiva de negocio como la perspectiva de TI mediante el uso de
tecnologías orientadas a procesos de negocio.

DESARROLLO DE PREGUNTAS

PREGUNTA 01: ¿Por qué están relacionados BPM y SOA?

Una forma de responder a esta pregunta es analizar las definiciones y/o descripciones tanto de
BPM como de SOA, sin embargo para el presente estudio en lugar de estudiar la relación a partir
de definiciones textuales se partirá de un modelo conceptual y el ciclo de vida de cada uno de los
temas en estudio para identificar los elementos comunes y los puntos en los que se vinculan, de
esta forma se demostrará porqué ambos temas están relacionados.

MODELO CONCEPTUAL Y CICLO DE VIDA DE BPM

Para elaborar el modelo conceptual de BPM se partirá de algunas definiciones que presentan
grupos de estudio y/o proveedores de soluciones BPM:

Definición de ABPMP: BPM es un enfoque disciplinario para identificar, diseñar, ejecutar,
documentar, monitorear, controlar y medir procesos de negocio automatizados o no, para
alcanzar resultados deseados y consistentes con las metas estratégicas del negocio. BPM involucra
la definición, mejoras, innovación y manejo de forma deliberada, colaborativa e iterativa y con la
ayuda de la tecnología, de los procesos de negocio de extremo a extremo (end to end) que
conduce los resultados de negocio, crea valor y habilita a la organización a alcanzar de forma ágil
sus objetivos de negocio.

Definición de IBM: Se puede definir a BPM como una disciplina o enfoque disciplinado orientado a
los procesos de negocio, pero realizando un enfoque integral entre procesos, personas y
tecnologías de la información. BPM busca identificar, diseñar, ejecutar, documentar, monitorear,
controlar y medir los procesos de negocios que una organización implementa. El enfoque
contempla tanto procesos manuales como automatizados y no se orienta a una implementación
de software. Algo importante a tener presente es que BPM no es una tecnología de software, pero
se apoya y hace uso de las mismas para su implementación efectiva. Dependiendo del uso del
Copyright © 2011, Ángel A. Yaulilahua Maraví (angel.yaulilahua@gmail.com).
Todos los derechos reservados. Prohibida su reproducción total o parcial o su uso comercial sin permiso expreso del
autor.

enfoque y su aplicación, BPM puede verse como una metodología, como una herramienta
estratégica o bien como conjunto de herramientas tecnológicas, no existe definición precisa, todo
depende del prisma que utilicemos para ver la realidad.

Definición de Intalio: BPM es un enfoque empresarial operativo basado en la coordinación de las
actividades y decisiones que todas las partes involucradas deben realizar durante un proceso de
negocio con el objetivo de convertirse en una organización altamente eficiente, ágil, innovadora y
adaptable.

Definición Software AG: BPM es un conjunto de métodos, herramientas y tecnologías utilizadas
para diseñar, representar, analizar y controlar procesos de negocio operacionales. BPM es un
enfoque centrado en los procesos para mejorar el rendimiento que combina las tecnologías de la
información con metodologías de procesos y gobierno. BPM es una colaboración entre personas
de negocio y tecnólogos para fomentar procesos de negocios efectivos, ágiles y transparentes.
BPM abarca personas, sistemas, funciones, negocios, clientes, proveedores y socios. BPM combina
métodos ya probados y establecidos de gestión de procesos con una nueva clase de herramientas
de software empresarial.

Definición Club BPM: Un conjunto de herramientas, tecnologías, técnicas, métodos y disciplinas
de gestión para la identificación, modelización, análisis, ejecución, control y mejora de los
procesos de negocio. Las mejoras incluyen tanto cambios de mejora continua como cambios
radicales. Resaltamos que no consiste en una solución tecnológica.

BPM = Gestión por procesos + gestión de procesos + tecnología BPM

En base a estas definiciones podemos sintetizar el tema de BPM (lo que implica hacer o
implementar BPM en una organización) con el siguiente modelo conceptual y ciclo de vida:

autor.

Modelo Conceptual

Fuente: Elaboración propia

ELEMENTO DESCRIPCION
Proceso de negocio El concepto central dentro de BPM, la noción de procesos
puede ser amplia dependiendo de la disciplina en estudio,
en BPM se abarca los procesos operacionales y que son
transversales a varias áreas de negocio o áreas funcionales.
Tareas humanas Actividades de un proceso que son ejecutadas por personas.
En implementaciones BPM es crítico/clave prestar atención
a los siguientes aspectos:
- Asegurar que las personas cuenten con toda la
información necesaria para ejecutar sus tareas.
- Medir el rendimiento e impacto de estas tareas en el
proceso.
Tareas de sistemas Actividades de un proceso que son ejecutadas en forma
automatizada por algún componente software.
Monitoreo de procesos No se puede gestionar lo que no se puede medir, en ese
sentido en las iniciativas BPM para poder gestionar los
procesos hay que definir indicadores para medir los
procesos.
Pasar del Modelado a la Ejecución Las tareas de automatización permiten pasar de una
mediante Tareas de definición de procesos (modelado) ha incorporar dicha
Automatización definición a la operación de la organización (ejecución). Lo
autor.

característico de BPM es poder pasar de manera
relativamente rápida del modelado a la ejecución de los
procesos.

Ciclo de vida BPM


Identificación Definir un mapa de procesos para la organización y a partir de
la estrategia de negocio identificar de procesos que entregan
valor.
Modelización Diseño o rediseño de los procesos identificados para una
iniciativa o proyecto BPM.
Implementación Automatizar los procesos para su ejecución, puede hacerse
mediante un desarrollo a la medida (Ing. de software) o
mediante tecnología orientada a procesos (BPMS y tecnologías
complementarias).
Ejecución Incorporar los procesos automatizadas a la operación de la
organización.
Monitorización Control de los procesos a partir de la información generada por

autor.

la ejecución.
Optimización Análisis de la información y toma de decisiones para mejorar
los procesos monitoreados.

MODELO CONCEPTUAL Y CICLO DE VIDA DE SOA

Para elaborar el modelo conceptual de SOA se partirá de algunas definiciones que presentan
grupos de estudio y/o proveedores de soluciones SOA:

Definición de SOA1: SOA es un estilo de arquitectura para construir sistemas basados sobre
orquestación débilmente acoplada, de grano grueso y componentes autónomos denominados
servicios. Cada servicio expone procesos y comportamiento a través de contratos que están
compuestos de mensajes para direcciones detectables denominadas endpoints. El
comportamiento de un servicio se rige por políticas que son externas al propio servicio. SOA es un
estilo de arquitectura, esto significa que SOA define componentes, relaciones y restricciones
acerca del uso e interacciones de cada componente. SOA define los siguientes componentes:
servicios, endpoint, mensaje, contrato, política y consumidor de servicio. SOA también define
ciertas interacciones que los componentes pueden tener.

Definición DBACCESS: Estilo de arquitectura de solución, basado en la definición y construcción de
servicios reutilizables que sustentan funciones del negocio. Los servicios encapsulan el acceso a la
información y la lógica de negocio permitiendo que las aplicaciones se integren bajo una visión
organizacional e independiente de las tecnologías utilizadas. El esquema de diseño e integración
está enmarcado por una serie de políticas que gobiernan su uso y evolución en el tiempo.

Definición IBM: Una arquitectura de aplicación en la cual todas las funciones se definen como
servicios independientes con interfaces invocables bien definidas, que pueden ser llamadas en
secuencias definidas para formar procesos de negocio.

Definición Software AG: SOA es una forma de mirar al mundo. Cuando se adopta una visión
orientada a servicios, todo cobra forma de servicio. Los servicios son los ladrillos con los que se
construye una SOA. Son un medio para acceder a las capacidades que se repiten en un negocio.
Los servicios SOA pueden acoplarse para construir otros nuevos, y ensamblarse en secuencias para
construir procesos.

1
Tomado del libro SOA Patterns (http://www.manning.com/rotem/)
autor.

Modelo conceptual SOA

Para el presente trabajo se tomará como referencia la siguiente representación2:

Asimismo se considerará el siguiente modelo conceptual:


2
Tomado del libro Open Source SOA (http://www.manning.com/davis/)
autor.

Servicio Es el concepto central de SOA, no está asociado a ninguna
implementación tecnológica específica sin embargo a
menudo se implementa como servicios web. Las principales
características de un servicio en SOA es que son de grano
grueso (alto nivel), reutilizables y autosuficientes (sin estado).
Típicamente los servicios SOA se identifican a partir de las
aplicaciones existentes (bottom-up) o a partir de las
necesidades de datos/información de los procesos de
negocio (top-down)
Consumidor de servicio Un servicio existe porque existen otros componentes
(consumidor de servicios) que hacen uso del mismo. Los
típicos consumidores de servicios son otros servicios, los
procesos de negocio y las interfaces de usuario.
Mensaje Es el elemento de comunicación en SOA. Servicios y
consumidores de servicios intercambian mensajes

Ciclo de vida SOA


autor.

ELEMENTO DESCRIPCIÓN
Identificar servicios Básicamente existen dos enfoques para identificar
servicios SOA. El enfoque top-down parte del análisis
de los procesos de negocio para identificar servicios
reutilizables entre diferentes procesos. Por otro lado el
enfoque bottom-up parte del análisis de las funciones
de las aplicaciones existentes para identificar servicios
a partir de funciones que se repiten en múltiples
aplicaciones.
Implementar servicios Un aspecto clave en SOA es definir una tipología de
servicios, es decir clasificar los servicios identificados
para poder elegir la tecnología apropiada para cada
tipo de servicio.
Registro de servicios Dado que los servicios son el concepto central de SOA,
para poder tener gobierno sobre la arquitectura SOA es
necesario tener un control centralizado lo cual se logra
a partir de un repositorio de servicios.
Consumir Servicios A partir del consumo de servicios, SOA permite dar
soporte a los procesos de negocio y combinar los
servicios para generar diferentes soluciones de
negocio.
Monitorizar servicios Siendo los servicios los ladrillos con los que se
construyen soluciones en SOA, es importante
monitorear el comportamiento de los servicios para
validar que cumplen el contrato que implementan y
dan soporte adecuado a la funciones de negocio que
automatizan.
Optimización A partir de la monitorización de los servicios y con el
apoyo de la tecnología SOA se puede aplicar diferentes
técnicas de optimización sobre los servicios de la SOA.

autor.

RELACION ENTRE BPM Y SOA

BPM y SOA desde una Perspectiva Organizacional

 Tanto BPM como SOA se encuentran en una ‘Zona Intermedia’ entre el mundo de los negocios
y el mundo de TI (tecnologías de la información). Ambos necesitan de la colaboración entre el
personal de negocio y el personal de TI para implementarse de manera exitosa. Tanto BPM
como SOA son medios para lograr los objetivos de la organización a partir de que
proporcionan elementos útiles para la ejecución de la estrategia de negocio

 En cierta forma BPM está cercano al mundo de los negocios ya que se centra en los procesos
de negocio y el personal de negocio es el principal interesado de que dichos procesos estén
adecuadamente gestionados para producir los resultados que espera la organización. Sin
embargo BPM, para lograr mejores resultados, necesita de un alto componente tecnológico
(tecnología orientada a procesos) por lo que no es raro que hayan proyectos BPM que surjan
como iniciativa del personal de TI.

 En cierta forma SOA está más cercano al mundo de TI dado que se origina como una evolución
de las arquitecturas distribuidas en la ingeniería de software. Sin embargo SOA tiene un fuerte
vínculo con el negocio debido a que el análisis de los procesos de negocio constituye una
buena fuente para definir servicios reutilizables y la composición de servicios responde a
necesidades de negocio y no a necesidades técnicas.

autor.

Fundamentos de la relación entre BPM y SOA

El vínculo o relación entre SOA y BPM se fundamenta en que sus modelos comparten
elementos comunes que son los puntos de complemento en sus respectivos ciclos de vida.

 Elementos compartidos:

ELEMENTO PERSPECTIVA BPM PERSPECTIVA SOA
Procesos Elemento central Fuente de identificación de servicios
reutilizables.
Un proceso automatizado también se
puede considerar como un servicio.
Servicios Soporte para las tareas de Elemento Central
sistemas.
Fuente de datos para la interfaz de
usuario en las tareas humanas
Información Hay que garantizar el flujo de Hay que implementar, combinar
información a lo largo del proceso servicios para proporcionar la
de negocio información que el negocio necesita.

CICLO BPM CICLO SOA DESCRIPCION DE LA RELACIÓN/COMPLEMENTO
Modelado Identificar servicios A partir del modelado de procesos y el análisis del
Optimización monitoreo de procesos de negocio se puede
identificar tareas de sistemas y/o decidir automatizar
algunas tareas humanas y servir de entrada para el
ciclo de vida SOA mediante la identificación de
nuevos servicios, la actualización o la composición de
servicios existentes.
Implementación Implementar servicios La automatización de procesos conlleva a la
implementación de servicios (nuevos servicios o
composición de servicios existentes) para el soporte
de las actividades de sistemas en los procesos.

autor.

Asimismo el proceso automatizado, dependiendo de
las tecnologías utilizadas, podría ser un nuevo servicio
implementado.
Ejecución Consumir servicios La ejecución de procesos conlleva al consumo de los
Monitorizar servicios servicios utilizados en su diseño, asimismo genera
Optimizar servicios información sobre el uso de los servicios para su
monitoreo y su posible optimización.

PREGUNTA 02: ¿Empezar por BPM o empezar por SOA? ¿Comenzamos por los servicios (bottom-
up) o los procesos (top-down)?

Para responder a esta pregunta hay que considerar que en el contexto de una organización
podrían presentarse los siguientes escenarios:

1. La organización todavía no se encuentra ejecutando proyectos ni BPM ni SOA.
2. La organización se encuentra ejecutando un proyecto BPM.
3. La organización se encuentra ejecutando un proyecto SOA.

La respuesta a esta pregunta se centra en el primer escenario con el objetivo de encaminar a la
organización hacia la implementación de BPM y SOA. En los otros escenarios (si ya hay proyectos
BPM o SOA en ejecución) la orientación es complementar el proyecto en ejecución con el otro
tema a partir de la relación entre ambos descrita en el desarrollo de la primera pregunta.

Partiendo de que el alcance de BPM y SOA no se limitan a un proyecto o una parte de la
organización sino a toda la organización, tanto la bibliografía de BPM y la de SOA coinciden en que
para la adopción (a nivel organizacional) de este tipo de soluciones es recomendable un enfoque
incremental (proyecto a proyecto) en lugar de tratar de hacerlo mediante un único ‘mega
proyecto’, en ese sentido y considerando la naturaleza complementaria descrita en el desarrollo
de la pregunta 01, no es necesario ‘terminar de implementar’ uno de ellos para recién empezar
con el otro, proyecto a proyecto ambos pueden ir implementándose de manera gradual.

Lo importante en la adopción incremental, proyecto a proyecto, es no perder el foco en el valor
de incremento en la adopción de BPM y SOA. La identificación de un proyecto que aporte en la
adopción/implementación de BPM en la organización (proyecto BPM) es bastante natural ya que
siempre habrá por lo menos un proceso de negocio dentro del alcance del proyecto, lo importante
es trabajar bajo el modelo conceptual de BPM y cubrir el ciclo BPM descritos en la pregunta 01
para considerarlo un “Proyecto BPM”. En el caso de los proyectos que aporten en la
adopción/implementación de SOA en la organización es un poco más complicado ya que
prácticamente cualquier proyecto de TI o relacionado a TI (integración de aplicaciones,
actualización de aplicaciones existentes, implantación de un BPMS, etc.) puede considerarse como
un “Proyecto SOA” siempre y cuando acerquen a la realización de una arquitectura global de
servicios para la organización por ejemplo a través de la elección de los servicios adecuados, de lo
contrario el proyecto de SOA sólo tendrá el nombre. De lo anterior se puede deducir que la clave
autor.

está en identificar los proyectos que aporten a la adopción/implementación de BPM, SOA o ambos
dentro de la organización.

Dado el enfoque de adopción incremental y la pregunta de ¿empezar por BPM o empezar por
SOA? Lo ideal sería empezar por ambos a la vez a través de proyectos que abarquen tanto
aspectos de negocio como aspectos de TI de tal manera que puedan aportar, a la vez, a la
adopción/implementación de SOA y BPM; sin embargo esto no siempre es posible, pese a las
bondades que ofrecen tanto BPM como SOA, debido a los costos de la tecnología BPM y la
tecnología SOA. Considerando que este trabajo está orientado a la adopción de SOA y BPM a lo
largo de una organización, la pregunta inicial se puede redefinir como ¿Cuál debería ser la primera
inversión, Invertir en tecnología BPM (Suite BPM) o invertir en tecnología SOA (suite SOA)?
Lógicamente dependiendo en qué tipo de tecnología se invierta primero, los proyectos que
ejecute la organización bajo la adopción incremental aportarán mayor valor a la adopción del
mismo tipo que la tecnología elegida, sin que ello signifique que el aporte a la adopción del otro
tema sea nulo, así mientras se avance en la adopción incremental llegará un momento en que se
invierta en el otro tipo de tecnología para completar los beneficios de una adopción integral de
BPM y SOA.

Para poder discernir por cuál empezar hay que analizar lo que implicaría empezar por BPM o
empezar por SOA:

Empezar por BPM implicaría:

 Centrarse en los procesos de negocio.
 Capacitación y uso de los estándares de BPM.
 Tener presente el complemento con SOA con miras a una implementación de BPM y SOA en
toda la organización.

Empezar por SOA implicaría:

 Centrarse en los servicios necesarios para construir soluciones a las necesidades de la
organización a través de la reutilización y combinación de dichos servicios.
 Capacitación y uso de los estándares SOA.
 Tener presente el complemento con BPM con miras a una implementación de SOA y BPM en
toda la organización.

Basado en estas implicancias podemos analizar los siguientes criterios para evaluar por dónde
empezar:

autor.

Criterios para decidir por dónde empezar

 Motivación y Justificación de los proyectos: Todas las iniciativas de gran alcance en una
organización necesitan para su implementación exitosa el respaldo o apoyo de los
responsables de las unidades de negocio o de la alta gerencia (el patrocinador o sponsor de los
proyectos). Por lo general los potenciales patrocinadores están más cercanos a las áreas de
negocio que las áreas de TI. Asimismo los “Proyectos BPM” y sus beneficios tienen un vínculo
más directo con las áreas de negocio que los “Proyectos SOA” y sus beneficios. En ese sentido
es más simple obtener la motivación y justificación para los “Proyectos BPM”.

 Facilitación del trabajo en equipo: Tanto los “Proyectos BPM” y los “Proyectos SOA”
requieren de una fuerte la colaboración entre el personal de negocio y el personal de TI para
su implementación exitosa. Dada la cercanía, vínculo o relación de SOA con la ingeniería de
software, los “Proyectos SOA” tienen potencialmente los mismos riesgos de ´divorcio´ entre el
personal de negocio y el personal de TI que en los proyectos de software siendo necesarios
analistas de negocio y/o analistas técnicos para traducir los requerimientos de negocio en la
implementación técnica. En los “Proyectos BPM” la situación es algo diferente ya que en estos
proyectos se suele utilizar la notación BPMN (Business Process Modeling Notation) que fue
creada con el objetivo de ser un lenguaje común entre el personal de negocios y el personal de
TI de esta forma el análisis se centra en el modelado del proceso y el flujo de flujo de
información a lo largo del proceso en lugar de diagramas de modelado de software. Los
estándares SOA están más orientados a personal técnico mientras que en BPM existe un
estándar (BPMN) que hace de lenguaje común entre todo el equipo y facilita el trabajo en
equipo. Por lo tanto la colaboración entre negocio y TI es más fuerte en los “Proyectos BPM”.

 Aporte para la adopción/implementación conjunta: Cuando se ejecuta un “Proyecto SOA” no
necesariamente se aporta a la adopción de BPM (por ejemplo proyectos de integración de
aplicaciones) sin embargo cuando se ejecuta un “Proyecto BPM” siempre se analiza uno o más
procesos de negocio, dicho análisis es una buena fuente para identificar “servicios SOA”
considerando que en la bibliografía SOA comúnmente se menciona dos enfoques para la
identificación de los servicios: 1° el enfoque bottom-up que consiste en identificar servicios a
partir de funcionalidad repetida en múltiples aplicaciones. 2° el enfoque top-down que
consiste en identificar servicios a partir del análisis de los procesos. Por lo tanto los “Proyectos
BPM” indirectamente aportan en la adopción de SOA (identificación de servicios) mientras que
un “Proyecto SOA” no siempre aporta en la adopción de BPM.

autor.

PREGUNTA 03: ¿Cómo se deben representar/especificar los 'requerimientos' para los proyectos
de BPM y SOA?

Del desarrollo de las preguntas anteriores también podemos inferir que cuando hablamos de
adoptarimplementar BPM no estamos hablando únicamente de crear diagramas de procesos,
estamos hablando de la gestión de los procesos de negocio a lo largo de todo el “ciclo BPM” lo que
generalmente implica la automatización de dichos procesos de negocio pero ¿Cómo hacemos la
automatización? Sin el uso de la “Tecnología BPM” dicha automatización se realiza mediante la
construcción de una aplicaciónsoftware por lo que al final terminamos hablando de
“Documentación de Procesos” y “Requerimientos de Software”, en ese sentido como punto de
partida para el desarrollo de esta pregunta es pertinente revisar la problemática en cuanto a
requerimientos de la Ing. de software.

Típico Proceso de Desarrollo – Ingeniería de Software

Fuente: Business Rules and Information Systems, Tony Morgan

De este proceso, para fines de este informe, se destaca las siguientes características:

 El dueño de negocio está alejado del proceso de desarrollo, una vez que se ha creado una
descripción inicial de las necesidades del negocio, típicamente en la forma de una
especificación de requerimientos, su participación está limitada a la interacción a través de
especialistas (analistas funcionales) y en el visto bueno final.
autor.

 El proceso se basa en gran medida en material descriptivo que tiene que ser interpretado por
personas con el tipo adecuado de habilidades para convertirlos en productos de desarrollo,
formándose una cadena de interpretación. Típicamente los analistas interpretan los
requerimientos de negocio para producir documentos de análisis, luego analistas técnicos o
diseñadores traducen los documentos de análisis en documentos de diseño que los
desarrolladores interpretan y traducen en código fuente para que los especialistas en pruebas
de software los validen previo a la validación o aprobación del usuario de negocio. Esta
secuencia introduce posibles puntos de malentendidos que pueden no detectarse sino hasta
muy tarde en el proceso, algo que podría compararse con el efecto del “teléfono malogrado”.

Cadena de interpretación – enfoque tradicional

Fuente: Business Process Management with JBoss jBPM, Matt Cumberlidge

Típico Proceso de Desarrollo Ágil - Ingeniería de Software

Cadena de interpretación – enfoque ágil

Fuente: Business Process Management with JBoss jBPM, Matt Cumberlidge

De este proceso, para fines de este informe, se destaca las siguientes características:

autor.

 La cadena de interpretación se reduce a la interacción directa entre el usuario de negocio y el
desarrollador.
 A diferencia del proceso tradicional para la comunicación entre el requerimiento de negocio y
la implementación se utilizan prototipos en lugar de documentos descriptivos.

Del análisis anterior se podría resumir dos puntos como los principales inconvenientes de la
automatización de procesos de negocio mediante el enfoque de la ingeniería de software:

1. Una vez implementados los requerimientos, la implementación no coincide del todo con la
necesidad de negocio que se tradujo en requerimientos de software. Esto se debe principalmente
a la cadena de interpretación y a los diferentes lenguajes utilizados por cada uno de los intérpretes
de la cadena lo que resulta en la necesidad de utilizar documentos descriptivos como elemento de
traducción.

2. Los cambios en los requerimientos suelen ser trabajosos de implementar por lo que no
responden, adecuadamente, al ritmo de los cambios en el negocio. Este inconveniente es una
consecuencia del anterior. Las actualizaciones o mantenimientos suelen demorar porque, bajo el
enfoque de la Ing. de Software, siguen casi el mismo ciclo que la implementación inicial y porque
todos los requerimientos se tratan de la misma forma (implementación a nivel de código), el
cambio no siempre lo hace la misma persona que lo implementó y nunca el mismo usuario de
negocio puede ejecutar los cambios. Todos los requerimientos se especifican e implementan
siguiendo el mismo patrón y siendo los casos de uso el elemento por defecto para representar
todo tipo de requerimientos.

Cuando trabajamos con BPM y SOA para automatizar los procesos de negocio disponemos de
elementos, técnicas, estándares y tecnologías para abordar esta problemática mediante el
lenguaje común que proporciona BPM a través de BPMN y mediante la agilidad que proporciona
SOA para construir rápidamente soluciones de negocio, sin embargo queda latente la interrogante
¿cómo debería abordarse los requerimientos para evitar los inconvenientes del enfoque de la
ingeniería de software?

Como aporte de este trabajo se sugiere tener en cuenta las siguientes directrices en lo que
respecta a requerimientos al abordar proyectos BPM y SOA:

1. Reducir tanto como sea posible la cadena de interpretación. Aquí es donde el enfoque de BPM
tiene un valor muy importante ya que permite pasar del modelado de procesos a la ejecución de
los mismos, se podría decir así que “el proceso es la aplicación”, aquí el elemento de comunicación
entre el personal de negocio y el de TI ya no es el típico caso de uso de la Ing. de software sino es
el proceso mismo que representa la realidad de la operación de la organización. El principal
estándar BPM que permite reducir la “cadena de interpretación” es la Notación de Modelado de
Procesos de Negocio (BPMN). BPMN mejora los esfuerzos organizacionales para alinear el trabajo
del personal de negocio y el personal de TI, proporcionando un lenguaje gráfico común, facilitando
la comunicación y mejorando la comprensión de los procesos de negocio.
autor.

La clave está en utilizar los diagramas de procesos en BPMN como elemento central de
comunicación, hablar de “requerimientos del procesos” (¿Cómo es y/o debe ser el proceso de
negocio?, ¿cuál es la responsabilidad de negocio y la responsabilidad de TI en el proceso de
negocio?, etc) en lugar de “casos de uso del sistema” como elemento intermediario entre negocio
y TI.


2. Pasar de requerimientos de software a requerimientos de información: Esto implica ver la
actividad del negocio como el flujo de información entre diferentes actores (humanos y
aplicaciones). Del desarrollo de las preguntas anteriores se puede inferir que tanto BPM como SOA
son, en alto nivel, “enfoques” de cómo gestionar la operación y la construcción de aplicaciones en
una organización, en ese sentido para comprender este punto voy a citar al conocido como “el
padre de la administración moderna” con respecto a los roles de los directores de negocio y TI en
una organización:

“Los directores generales deben aceptar que si el ordenador es una herramienta, es tarea del
usuario de esa herramienta decidir cómo usarla. Deben asumir la “responsabilidad de la
información”. Y eso significa preguntar: ¿Qué información necesito para hacer mi trabajo? ¿De
quién? ¿En qué forma? ¿Cuándo? Y también: ¿Qué información debo dar? ¿A quién? ¿En qué
forma? ¿Cuándo? Por desgracia, la mayoría sigue esperando que el director del departamento de
informática o algún otro técnico responda a esas cuestiones. Y eso no puede ser… El director de
Informática es quien fabrica la herramienta, el director general quien la usa”

autor.

La empresa en la sociedad que viene. Peter Drucker

De esta cita hay que resaltar dos aspectos:

 La información como recurso para la operatividad de la organización.
 La responsabilidad del personal de negocio (operación) sobre el “recurso información” para
realizar su trabajo y colaborar con los demás.

Un diagrama BPMN si bien sirve para la comunicación entre negocio y TI, queda incompleto si
no se especifica el flujo de información a lo largo del proceso, la tarea de determinarespecificar el
flujo de información en el proceso permite poner énfasis en la “responsabilidad de la información”
de cada participante de negocio en el proceso (información que necesita e información que
agrega) al analizar las tareas humanas, asimismo también se enfatiza la responsabilidad del área
de TI para la adecuada gestión del recurso información (obtención, visualización, procesamiento,
persistencia, etc.) a lo largo del proceso resultando en una o más tareas de sistemas requeridas
para la ejecución del proceso.

La clave está en analizar “los requerimientos de información” de los procesos de negocio,
incorporar prácticas de “gestión de la información” y así, en forma gradual, ir definiendo un
“Sistema de Información Organizacional”.


3. Clasificar o tipificar los requerimientos según el formato o soporte especializado que exista
para cada tipo de requerimiento: No tenemos que trabajar todos los requerimientos de la misma
forma, existen diversos tipos de requerimientos y cada tipo tiene sus propias características, por
ejemplo la frecuencia de cambio, que en la actualidad existen soluciones especializadas para
ciertos tipos de requerimientos tales como:
autor.

 Las soluciones de ECM: para gestión de contenidos.
 Las soluciones de BRMS: para la gestión de reglas de negocio.
 Los mismos BPMS: para requerimientos de gestión de procesos de negocio.

Por lo tanto no es necesario especificar todos los requerimientos como “casos de usos” y
“Diagramas UML”, en su lugar se deberían utilizar los formatos propios de cada tipo de
requerimientos (por ejemplo tablas de decisión para las reglas de negocio, BPMN para los
procesos, etc). Sin embargo no hay que perder de vista que los “Servicios SOA” son componentes
de software y en dicho caso se debería usar los elementos que dispone la Ing. de Software.

Quizá el ejemplo más representativo de este tercer grupo son los BRMS (Business Rules
Management System) que permiten la definición y modificación de las reglas de negocio por parte
del mismo usuario de negocio, lo que permite que este tipo de requerimientos que son
frecuentemente cambiantes puedan reflejar los cambios en forma automática y transparente.

La clave está en comprender que no es necesario implementar todos los requerimientos desde
cero (código fuente) y evaluar el uso de estas soluciones especializadas como parte de la
automatización de los procesos de negocio. Un punto a favor del uso de estas soluciones
especializadas es que por lo general exponen su funcionalidad como “web services” y ello facilita
su incorporación en un contexto BPM&SOA.

A modo de ejemplo para procesos de negocio que sean intensivos en trámites o gestión
documental podría usarse el siguiente proceso para la especificación de sus requerimientos:

autor.


autor.

BPM Chile Day 2011 - Informe BPM&SOA

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (17)

Similar a BPM Chile Day 2011 - Informe BPM&SOA

Similar a BPM Chile Day 2011 - Informe BPM&SOA (20)

Último

Último (20)

BPM Chile Day 2011 - Informe BPM&SOA