lunes, 31 de octubre de 2011

Patrones de implementación SOA

Service Data Replication
¿Cómo es posible preservar la autonomía de un servicio cuando los servicios requieren acceso a fuentes de datos compartidas?
Problema:
La lógica del servicio puede desplegarse de manera aislada para incrementar la autonomía del servicio, pero los servicios siguen perdiendo su autonomía cuando requieren el acceso a fuentes de datos compartidas.





Solución:
Los servicios pueden tener sus propias fuentes de datos replicadas de las fuentes de datos compartidas.




Aplicación:
Se requiere tener una base de datos adicional para almacenar la información requerida por el servicio, además se requiere proveer uno o más canales de replicación para sincronizar la información.

Impactos:
Este patrón resulta en costos de infraestructura adicional, además manejar los canales de replicación adicionales puede ser difícil de administrar.

Opinión:
El patrón se encuentra orientado a garantizar la autonomía de los servicios, pero la preservación de dicha autonomía viene con un alto costo en infraestructura y administración de los canales de replicación. El patrón puede ser útil en servicios que son altamente reutilizados, y/o que son necesarios para la composición de otros servicios. Si este patrón se implementa en muchos servicios de un inventario se puede requerir una modificación compleja de la infraestructura de datos de la empresa.

Patrones de Seguridad en SOA

Debido a soluciones orientadas a servicios se componen típicamente de servicios agregados, cada componente dentro de una arquitectura de composición de servicios puede convertirse en un blanco potencial de violación de seguridad. Las arquitecturas de servicios necesitan ser provistas de controles adicionales que les permiten soportar las formas más comunes de ataques de consumidores maliciosos.

Patrón de Subsistema de Confianza

Problema

Cuando los recursos subyacentes de servicios, tales como bases de datos, se puede acceder directamente por los programas de los consumidores, la seguridad de los recursos puede verse comprometida por atacantes maliciosos y/o programas de los consumidores que pueden formar dependencias no óptimas en los componentes de una arquitectura de servicios que pueden conducir a formas negativas del consumo de servicios acoplados. Este problema se puede esquematizar en la siguiente figura:



Solución

El servicio actúa como un subsistema de confianza de sus recursos subyacentes. Los consumidores sólo pueden acceder a los recursos a través del servicio y el servicio utiliza sus propias credenciales en lugar de las credenciales de los consumidores para llevar a cabo el acceso a los recursos.

Varios enfoques y tecnologías pueden ser utilizados para implementar este modelo:

- Utilización de cuentas de servicio se en el subsistema de confianza. Un método común de implementación de verificación es el protocolo Kerberos es utiliza una cuenta de servicio dentro del subsistema de confianza.

- Utilización de Cuentas locales en cada host. Cuando no sea posible realizar la autenticación de las cuentas de servicio mediante Kerberos, se puede crear una cuenta local en cada equipo en el subsistema de confianza. Este tipo de cuentas son como "cuentas espejos", donde cada uno tendrá el mismo nombre de usuario y contraseña. Estas"cuentas espejo", requieren contraseñas complejas que necesitan ser cambiadas con regularidad.

- Utilizando un método de autenticación como PKI (Infraestructura de Clave Pública) y el estandar X.509 se utiliza para la autenticación en el subsistema de confianza. PKI X.509 puede generar un certificado para cada aplicación dentro de un subsistema de confianza. Para acceder a los recursos del servicio debe utilizar un certificado X.509, como base para la autenticación. Además, el certificado debe estar en la lista de certificados que están autorizados a acceder al recurso.

- Utilizar IPSec entre equipos en el subsistema de confianza para que la comunicación sea segura. IPSec asegura mensajes entre dos equipos en la capa de red para proporcionar confidencialidad e integridad de datos. Puede ser configurado para iniciar una comunicación segura con el protocolo Kerberos, certificados X.509, o una clave previamente compartida. IPSec funciona considerablemente mejor que la seguridad en la  capa de mensajes, pero no permite un control granular de los recursos. Esto se debe a que, con IPSec, un subsistema de confianza sólo se puede establecer entre los equipos que participan en el subsistema de confianza y no en un programa específico para acceder a un recurso específico. La solución a este problema se puede esquematizar en la siguiente figura:



Impactos

Si un servicio de implementación del Subsistema de confianza está en peligro, que puede ser utilizado para explotar los recursos indirectos que tiene acceso. Por esta razón, los servicios que actúan como subsistemas de confianza a menudo se vuelven los principales objetivos de los atacantes de la sonda en busca de vulnerabilidades dentro de la empresa.

Patrón de Servicio de Seguridad Perimetral

Problema

Los consumidores externos necesitan tener acceso a uno o más servicios desplegados en una red privada. Al proporcionar un acceso directo a la red privada los servicios son expuestos a los atacantes externos que pueden obtener la información interna y utilizarla para comprometer los servicios y la red. Este problema se puede esquematizar en la siguiente figura:


Solución

Colocar un servicio de intermediación en el perímetro de la red privada y se establece como el punto de contacto único para los consumidores externos para que pueden acceder a servicios internos.

Este tipo de servicio suele ser desplegados en una red perimetral (también conocida como DMZ o zona desmilitarizada), que tiene acceso a los recursos de la red privada a través de un firewall. Funciona en la capa de aplicación y su objetivo es trabajar en conjunto con las tecnologías de firewall existentes (y no para sustituirlos). Un consumidor externo enviará un mensaje de solicitud dirigida zona externa del servicio perimetral, que a su vez reenvía a los servicios internos. Del mismo modo, cuando un servicio interno responde, los servicios del tipo Relay de la zona perímetral da una respuesta a los consumidores externos. A lo largo de este intercambio, la ubicación y el contrato del servicio interno permanece oculto a los consumidores externos.

Una de las principales ventajas del servicio perimetral de seguridad es que se puede establecer el proceso de seguridad centralizada en nombre de otros servicios. Esto permite una arquitectura que se construirá en torno a un perímetro de servicios capaz de implementar otros modelos de seguridad. La solución a este problema se puede esquematizar en la siguiente figura:



Impactos


El uso de los servicios de perímetrales pueden agregar complejidad y la sobrecarga de procesamiento y además puede presentar problemas de rendimiento cuando sea necesario dirigir y aplicar el proceso de seguridad a un gran número de mensajes. Como el único punto de entrada para una red privada, este tipo de servicio también puede convertirse en un objetivo principal para los atacantes. Esto requiere que los servicios perimetrales sean lo suficientemente robustos para soportar ataques masivos. Además, el uso de este patrón no reduce la necesidad de asegurar los servicios internos, especialmente en relación con la comunicación que debe producirse entre servicios interior y servicios perimetrales.

lunes, 24 de octubre de 2011

Identificación de servicios usando SOMA

La metodología define un conjunto de técnicas complementarias para identificación de servicios: descomposición de dominio, análisis de activos existentes, y modelado de metas de servicio (goal service modeling)

Aplicamos estas tres técnicas a nuestro caso de estudio Vehialpes, y así formamos un grupo de servicios candidatos, los cuales componen nuestro portafolio de servicios candidatos.

Descomposición de Dominio:


Esta es una técnica TOP-DOWN, en la cual se descompone el dominio de negocio en áreas funcionales y subsistemas, hasta llegar a procesos, subprocesos y tareas.

Decidimos omitir la fase de análisis de áreas funcionales y apoyarnos en los modelos de proceso de negocio existentes . De esta manera, identificamos los siguientes servicios agrupados según el proceso del cual se originan:

  • Proceso de Garantía
    • Revisar cumplimiento
    • Generar factura consumibles
    • Generar orden de garantía
    • Ingresar vehiculo
    • Asginar orden de revisión
    • Solicitar consumibles
    • Entregar consumibles
    • Entregar vehículo
    • Generar informe de garantía
  • Proceso de mantenimiento
    • Asignar cita
    • Ingresar vehículo*
    • Generar orden de mantenimiento*
    • Asignar mecánico*
    • Registrar mantenimiento
    • Solicitud de parte *
    • Registrar entrega de partes *
    • Facturar mantenimiento *
    • Procesar pago
    • Registrar mantenimiento
    • Generar orden de entrega
    • Hoja de vida del vehículo
Los servicios candidatos marcados con * son servicios comunes a ambos procesos. Evidentemente esta técnica ayuda a identificar servicios comunes a varios procesos. De esta manera decidimos eliminar los servicios redundantes, por lo que nuestro portafolio de servicios en esta etapa, es el siguiente:

Portafolio de Servicios tras análisis TOP-DOWN mediante la técnica de descomposición de domino:
  • Revisar cumplimiento
  • Generar factura consumibles
  • Generar orden de garantía
  • Ingresar vehículo
  • Asginar orden de revisión
  • Solicitar consumibles
  • Entregar consumibles
  • Entregar vehículo
  • Generar informe de garantía
  • Asignar cita
  • Registrar mantenimiento
  • Procesar pago
  • Registrar mantenimiento
  • Generar orden de entrega
  • Hoja de vida del vehículo
Continuamos identificando servicios ahora utilizando al técnica BOTTOM-UP de análisis de activos existentes 

Análisis de Activos Existentes:

Basados en el enunciando del problema y las discusiones en clase, identificamos las siguientes aplicaciones existentes en Vehialpes, y analizamos su funcionalidad a muy alto nivel
  • Aplicación para el control de importación
    • Manejo de tramites importacion de vehiculos
  • Aplicación manejo de garantía
    • Validación de garantía
    • Generar orden de pago de garantía
  • Aplicación utilizada en el callcenter
    • Quejas y reclamos
    • Redirección de quejas
    • Actualización de datos de cliente
  • Aplicación de inventarios y repuestos
    • Alimentar base de datos partes en stock
    • Consultas y reportes de inventario de repuestos
  • CRM
    • Manejo de información de clientes
    • Quejas y reclamos
De la funcionalidad de las aplicaciones existentes decidimos incluir en el portafolio de servicio los siguientes servicios adicionales:

  • Manejo inventario de partes
  • Manejo información cliente
  • Generar orden de pago taller
Una de los aspectos a mencionar es que al utilizar esta tecnica nos dimos cuenta que habiamos pasado por alto servicios necesarios para el manejo de nuestros procesos, e identificamos la necesidad de generar una orden de pago al taller cuando se presenta una reclamacion de garantia

Por ultimo, aplicamos la tercera técnica de la metodología SOMA: Goal Service Modeling.

Para esta técnica decidimos utilizar como meta de negocio la fidelizacion de clientes, descompusimos esta meta hasta llegar a un servicio para utilizar en nuestra aplicacion web, de la siguiente manera:

Meta: Fidelización de clientes
Submeta: Aumentar el uso de talleres autorizados

Descomponiendo esta submeta en: Fomentar la comunicación entre VehiAlpes y red de talleres.

En este punto alcanzamos el "aha factor", al encontrar que esta submeta la podemos alcanzar ofreciendo un servicio de hoja de vida del vehículo. Capacidad que podemos ofrecer mediante una aplicación de hoja de vida para dispositivos móviles, exponiendo un servicio web el cual adicionamos a nuestro portafolio de servicios.

Nuestro catalogo de servicio tras aplicar las tres técnicas es:
  • Revisar cumplimiento
  • Generar factura consumibles
  • Generar orden de garantía
  • Ingresar vehículo
  • Asginar orden de revisión
  • Solicitar consumibles
  • Entregar consumibles
  • Entregar vehículo
  • Generar informe de garantía
  • Asignar cita
  • Registrar mantenimiento
  • Procesar pago
  • Registrar mantenimiento
  • Generar orden de entrega
  • Hoja de vida del vehículo
  • Servicio consulta dispositivos móviles
  • Manejo inventario de partes
  • Manejo información cliente
  • Generar orden de pago taller

domingo, 16 de octubre de 2011

Integración de Aplicaciones Empresariales a través de Patrones de Mensajería

La creciente interconexión entre los sistemas de información y la integración de aplicaciones se ha convertido en un importante tema que va más alla de los aspectos técnicos. Las consecuencias financieras y de negocios de integración de aplicaciones puede ser inmensa. La comunidad informática está generalmente más interesada ​​en el desarrollo e implementación de arquitecturas empresariales que en los mecanismos de integración entre las aplicaciones.  En esta ocasión nos enfocamos en la integración a través de mensajes. La mensajería es la clave para la integración y es el enfoque predominante en los servicios web en los próximos años.

La mensajería es una tecnología que permite la comunicación entre programas con una entrega confiable. La comunicación entre programas se hace mediante el envío de paquetes de datos llamados mensajes a través de canales que son las vías lógicas que se conectan los programas y transmiten los mensajes.

Las funciones de mensajería son provistos por un sistema de software independiente denominado sistema de mensajería o middleware orientado a mensajes (MOM) por medio de estándares de integración como RPC, CORBA o DCOM. Un sistema de mensajería gestiona mensajes de la forma en que un sistema de base de datos maneja la persistencia de datos. Al igual que un administrador debe rellenar la base de datos con el esquema de los datos de una aplicación, el administrador debe configurar el sistema de mensajería con los canales que definen las rutas de comunicación entre las aplicaciones. 

Orquestación de Procesos a través de Mensajería

Los servicios Web son apoyados por una pila de estándares de Internet (HTTP, XML, SOAP, WSDL y UDDI), que debía ser complementada por una capa de procesos, ya que son escenarios de negocio basados en procesos. En el nivel de ejecución, estos modelos se utilizan para la orquestación de procesos. Orquestación, en este contexto describe la composición de los objetos de negocio en un flujo de proceso. En detalle, se define una compleja interacción entre los objetos de negocio, incluyendo la lógica de negocio para la ejecución de las interacciones.

Sin objetos de negocio a orquestar, el contexto general entre los pasos del proceso se perdería. Los colaboradores del proceso deben tener la posibilidad de acceso a datos y aplicaciones de una manera fácil y segura. Coreografías por otro lado definen la colaboración entre las partes que interactúan. Tanto la orquestación como coreografías en la interacción  de objetos de procesos de negocio se puede lograr mediante la implementación de funciones de un sistema de mensajería a nivel de middleware.

 
Patrón de Orquestación de Procesos

Como ejercicio académico y partiendo de la notación de coreografía de BPMN 2.0 se diseñó un nuevo patrón de orquestación de procesos. Luego se modeló el proceso con BPEL integrando OpenESB.

Continuando con el modelamiento de la arquitectura empresarial incorporamos patrones de mensajería a nivel de integración que nos permita posteriormente incorporar o diseñar patrones de mensajeria SOA.

 
Modelo Proceso BPEL: Solicitud de Garantía


lunes, 10 de octubre de 2011

BPMN, Patrones de Integración Empresarial, Integración de Aplicaciones

De las tres lecturas para la clase de esta semana, la primera continuaba con el tema de BPMN y las dos restantes, sobre el nuevo tema de integración empresarial..

La primera lectura, de Thomas Allweyer, presenta una introducción a BPMN 2.0.

A través de ejemplos,  se presenta la notación completa. Aunque no se entra en detalle en el campo de los metamodelos, el autor si hace énfasis en que BPMN no es solo una notación y despierta la curiosidad del lector sobre este tema. Igualmente, se tiene en cuenta aspectos de la ejecución de los modelos presentados a lo largo del libro.

En comparación con el libro de Silver estudiado en clases anteriores, este texto de Allweyer resulta mucho más claro y placentero de leer.

En la lectura Enterprise Integration Patterns se presenta, de una manera un tanto similar a la del libro de Allweyer, un primer ejemplo en el que se explican, teniendo en cuenta restricciones bastante comunes en la practica, patrones que se estudian más en detalle posteriormente.

El lenguaje y ambiente más técnico, comparado con las otras lecturas tratadas anteriormente en la clase, en donde incluso se muestran fragmentos de código, ha de resultar muy recomfortante para quienes puedan haber sentido que los temas tratados anteriormente han sido demasiado "para administradores".

Por ultimo, vale la pena resaltar la muy buena definición de Loose Coupling basado en minimizar el numero de asunciones al comunicarse.

La tercera lectura acerca de integración de aplicaciones comienza con un recuento basatnte interesante de la integración haciendo una analogía geografica y urbana.
En conjunto, en esta última lectura si bien mucho más puntual en cuanto a que trata especialmente el área de aplicaciones de negocios, se pueden apreciar varios patrones descritos en la lectura de  Enterprise Integration Patterns.


En general, con estas lecturas queda bastante claro BPMN 2.0, y se presenta un nuevo tema bastante interesante y para muchos quizás más familiar a la ingeniería de sistemas.

Patrones y BPMN - Propuesta de un nuevo patrón


Como ejercicio académico y usando como apoyo la notación de coreografía de BPMN 2.0 se creó el diseño de un nuevo patrón.

Patrón autorizador


Problema
En un flujo de procesos es muy frecuente que se presenten situaciones en las cuales se requiere la aprobación de una actividad puntual. Autorizar el uso de una garantía, la aprobación de un préstamo bancario o la autorización de un pago con tarjeta de crédito son algunos ejemplos que muestran la razón por la que se propone el nuevo patrón.

Motivación
Delegar a un tercero la autorización  de actividades evita que uno o varios procesos de negocio tengan que re-plantear una tarea que puede ser modelada de una forma estándar y que se puede aplicar transversal al flujo normal de eventos.

Aplicación
El Autorizador, es un patrón sencillo y permite un uso amplio en cualquier área. Desde servicios financieros (autorización de productos a un cliente), hasta procesos administrativos (autorización para compra de papelería de las oficinas).

Estructura

lunes, 12 de septiembre de 2011

Propuesta de Innovación para VehiAlpes

Nuestra propuesta de innovación busca aumentar la retención de los clientes mejorando el servicio postventa Los cambios propuestos al modelo de negocio de Vehialpes se reflejan en el canvas y reflejan los patrones de una multisided platform .

Las posibilidades de interactuar con los dos lados del  plataforma: clientes finales (consumidores) y concesionarios son muchas. Consideramos que el paso más importante es interconectar la plataforma actual de Vehialpes (que gira en torno a los vehiculos) y la plataforma de servicio postventa, que se enfoca en los clientes. Por esta razón  decidimos realizar una aplicación para el manejo de las hojas de vida de los vehículos.

Por medio de esta aplicación el propietario y VehiAlpest tienen el seguimiento de todas las actividades de mantenimiento y de garantía para su vehículo (Bitácora del Vehículo). En el momento de la venta se le entregará junto con la carta de garantía una tarjeta en la que encontrará los datos de acceso para esta aplicación.

Toda solicitud de mantemiento, repuestos o garantía debe ser tramitada a través de esta funcionalidad.
Con este desarrollo se logra lo siguiente:

- Se crea un canal único de comunicación entre propietario y proveedor del Vehículo (VehiAlpes).
- Se puede realizar seguimiento a todo el proceso postVenta de los vehículos de VehiAlpes
- Se puede crear una funcionalidad para envío de mensajería a móviles y correos electrónicos del propietario cada vez que se realice alguna actividad sobre el vehículo. (De esta manera se trata de garantizar que si sea el propietario quien solicite el respectivo mantenimiento o garantía)
- A través de estos medios y de la hoja de vida del vehículo se podrán hacer campañas para fidelización del cliente hacia la marca y para promover un mayor uso de los talleres autorizados.
- La aplicación estará en línea y por tal razón los talleres se verán obligados a registrar por medio de ella cualquier mantenimiento o garantía prestada a los vehículos. Si no se hace de esta manera, la pieza o servicio realizado no contarán con garantía.

Propuestas reflejadas en el canvas del modelo de negocio



















Modelamiento de Procesos de Negocio de VehiAlpes

Proceso de Gestión de Garantias


Proceso de Mantenimiento



























































lunes, 5 de septiembre de 2011

BPM y BPMN

En la actualidad las compañías se enfrentan a necesidades dinámicas generadas por múltiples factores tales como la competencia, las amenazas del mercado o la posibilidad de aprovechar nuevas oportunidades; la tecnología puede convertirse en un cuello de botella cuando no puede adaptarse rápidamente para enfrentar estas situaciones. Business Process Management (BPM) es una herramienta que ayuda a las organizaciones en la mejora continua de sus procesos de negocio, permitiendo que los modelos que dirigen la compañía evolucionen constantemente y se adapten a estas necesidades.

De acuerdo con Bill Gates “The first rule of any technology is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency”, es importante tener en cuenta que el primer paso para tener una organización dinámica que se enfrente con facilidad a los retos y oportunidades del mercado es revisar que los procesos estén alineados con las estrategias y objetivos organizacionales y que además sean eficientes; ya que, como se ha visto a través de los años las organizaciones tienden a comprar soluciones automatizadas porque: no conocen los detalles de sus procesos pero saben que de alguna manera generan salidas (black box syndome), o porque tratan sus procesos y las personas relacionadas como objetos sagrados y solo miran a las afueras del problema (looking at the edges syndrome); pero la realidad es que la automatización de procesos no soluciona los problemas subyacentes, sino que por el contrario, ayuda a que ocurran más rápido y a mayor frecuencia. Todo esto indica que el orden correcto es arreglar los procesos, antes de mirar a soluciones automatizadas.

¿Cómo se estructura BPM ?

BPM descansa sobre tres pilares fundamentales: procesos, personas y tecnología. Pero además existe un cuarto componente sobre el que recae el éxito de un proyecto BPM: la administración del proyecto. Las personas son un componente clave dentro de BPM, ya que no solo se trata de alineación de estrategia y procesos, sino también de personas y su comportamiento. Ninguna solución (tecnológica o no) puede ser exitosa si las personas involucradas en el desarrollo de los procesos no creen en lo que se está desarrollando, o si se ven amenazados por la solución presentada.

El 7FE Project Framework propuesto por John Jeston and Johan Nelis, provee una estructura que permite el desarrollo de un proyecto BPM en una organización. 7FE está conformado por 10 fases, estructuradas en grupos: Un primer grupo compuesto por 4 Fs: foundation, findings & solutions, fulfillment y future; y un grupo de 3 Essentials: Leadership, Project management y people change management.


El framework empieza desde la estrategia organizacional la que debe ser considerada para el planteamiento de la arquitectura de procesos, ya que los procesos "per-se" no corresponden a un objetivo final, sino a un camino para llegar a los objetivos. Es importante en la etapa de la creación de la arquitectura de procesos considerar que se pretende atacar problemas dinámicos y por ello la arquitectura debe ser como lo manifiestan Jeston y Nelis “just enough, just in time”. En la fase "Launch Pad" se selecciona donde empezar el proceso BPM, se fijan las metas una vez se han seleccionado los procesos y se establece el proyecto.

El grupo "Findings and Solutions" involucran las fases "Understand e Innovate", en las que se busca que los interesados en el proceso tengan suficiente entendimiento de los procesos de negocio para proponer soluciones; aquí se selecciona las opciones que se van a implementar a través de las fases restantes.

El grupo "Fulfillment" se desarrollan 3 fases. La fase Develop se encarga de la construcción de todos los componentes necesarios para la implementación del nuevo sistema. La fase People tiene como objetivo asegurar que las actividades, los roles y las medidas de rendimiento se encuentren alineados con la estrategia organizacional y con los objetivos de los procesos. Por último, la fase Implement es donde todos los aspectos del proyecto ocurren.

En el grupo Future se asegura que los beneficios manifestados en el caso de negocio realmente se consiguen y además se busca la conversión de que BPM se vuela una actividad operacional de negocio y no solo sea un proyecto.

¿Cuáles son los fundamentos de un proyecto BPM ?

Los proyectos, sin importar su nivel tecnológico, alcance o propósito, se fundamentan en una serie de factores necesarios para su correcta implementación. En el caso de la implementación de proyectos BPM, existen tres componentes fundamentales sobre los que que recae éxito de un proyecto de esta naturaleza:

1. Gestión de Proyectos

La gestión de proyectos se refiere al conjunto de responsabilidades y de acciones necesarias para materializar el proyecto (consolidación de componentes) y para realizar su objetivo específico (propósito). Por lo tanto, es importante que un proyecto BPM sea gestionado por expertos en esta materia con habilidades fundamentales para guiar y dirigir en proyecto en la dirección correcta. Es importante que se cumplan con ciertos requisitos específicos en proyectos BPM dada la complegidad y exigencia de conocimientos, habilidades y destrezas en este tipo de proyectos.

2. Gente orientada al Cambio

Realizar un proyecto significa cambiar. Quien consigue gestionar adecuadamente sus proyectos, tiene más posibilidades de éxito y, por lo tanto, más probabilidades de sobrevivir. Por eso hoy, las organizaciones no buscan personas capaces de cambiar, de adaptarse a los cambios. Buscan personas capaces de realizar los cambios, de liderarlos, de dirigirlos. Personas capaces de llevar a la organización a su siguiente estado en la evolución empresarial.

3. Liderazgo

Para garantizar el éxito en la implementación de un proyecto BPM, es necesario contar con liderazgo al interior de la orgnización y el suficiente apoyo político en sus estamentos directivos que permita para alcanzar los objetivos y metas que se persiguen al implementar un proyecto BPM.

¿Qué herramientas permiten llevar a cabo el desarrollo de un proceso BPM ?

BPMN (Business Process Modeling and Notation) es una notación gráfica fundamental dentro del desarrollo de un proyecto BPM. BPMN, a través de una notación estándar, permite que todos los stakeholders puedan modelar procesos de negocio de una manera fácil y entendible, agilizando la comunicación y la proposición de soluciones a los problemas en los procesos de negocio.

El departamento de TI de una organización, se ve enormemente beneficiado por el uso de BPMN, ya que los procesos construidos mediante esta herramienta encajan con modelos tecnológicos como SOA (Service Oriented Architecture), permitiendo la agilización de la construcción de soluciones lo cual es fundamental para dar respuesta en el momento adecuado a las oportunidades y retos que ofrece el mercado para la organización.