MXPA00012056A - Sistema y metodo para menejar la colaboracion dentro y entre empresas - Google Patents

Abstract

Se proporciona un proceso implementado por computadora para la colaboración de empresas. El proceso incluye el almacenar un juego de funciones predefinidas para un flujo de trabajo que va a llevarse a cabo en una pluralidad de nodos distribuidos. El proceso automáticamente interactúa con el flujo de trabajo en cada uno de los nodos distribuidos para llevar a cabo las funciones predefinidas.

Description

MÉTODO Y SISTEMA PARA MANEJAR LA COLABORACIÓN DENTRO Y ENTRE EMPRESAS Campo Técnico de la invención Esta invención se refiere en general al campo de la cadena de suministro, de la empresa y de planeación de sitio, y más particularmente, a un sistema y a un método para mane] ar una colaboración dentro o entre empresas.

Antecedentes de la Invención Las aplicaciones de cadena de suministro, de empresas y de planeación de sitio y los ambientes de estos son ammpliamente usados por las entidades fabricantes para el soporte de decisión y para las operaciones de manejo de ayuda. Lo ambientes de soporte de decisión para la cadena de suministro, para la empresa y para la planeación de sitio han evolucionado de ambientes de dominio único, monolíticos a ambientes monolíticos de dominios múltiples. Las aplicaciones de software de planeación convencional están disponibles en un rango amplio de productos ofrecidos por varias compañías Estas herramientas de soporte de decisión permiten a las entidades el manejar más eficientemente las operaciones de fabricación complejas. Sin embargo, las cadenas de suministro son generalmente caracterizadas por ambientes de planeación múltiples, distribuidos y heterogéneos.

Por tanto, hay límites a la efectividad de los ambientes convencionales cuando se aplican al problema de la planeación de cadena de suministro debido a las arquitecturas de aplicación monolítica. Además, estos problemas son exsacervados cuando no hay un "propietario" de la cadena de suministro completa.

Es deseable para el siguiente paso evolucionarlo para los ambientes de planeación de arquitectura heterogénea el establecer un proceso de dominios múltiples que soporte los dominios múltiples de extensión de productos así como los motores y productos múltiples de extensión. La integración de los varios ambientes de planeación en una solución sin costura puede habilitar la planeación de cadena de suministro entre las empresas y entre los dominios. Además, una función importante proporcionada por algunas aplicaciones de planeación es la optimización del ambiente de sujeto más bien que el simplemente seguir rastro de las transacciones. En particular, la familia RHYTHM de productos disponibles de 12 TECHNOLOGIES proporcionan una funcionalidad optimizada. Sin embargo, con respecto a la planeación en una empresa o al nivel de cadena de suministro, muchas aplicaciones convencionales, tal como aquellas disponibles de SAP, usan los motores de planeación de recursos de empresa (ERP) y no proporciona la optimización.

El éxito o falla de una empresa puede depender en gran extensión de la calidad de la realización de decisión dentro de la empresa. Por tanto, el software de soporte de decisión, tal como la familia de productos RHYTHM de I2 TECHNOLOGIST, que soportan la realización de decisión óptima dentro de las empresas puede ser particularmente importante para el éxito de la empresa. En general, las decisiones óptimas son relativas al dominio del soporte de decisión en donde el dominio es la extensión del "mundo" considerado para llegar a la decisión.

Por ejemplo, la decisión que está siendo hecha puede ser qué tanto de un artículo dado una fábrica puede producir durante un periodo de tiempo dado. La respuesta "óptima" depende del dominio de la decisión. El dominio puede ser, por ejemplo, justo la fábrica misma, la cadena de suministro que contiene la fábrica, la empresa completa o la cadena de suministro de empresas múltiples. (Estas últimas dos pueden ser consideradas conociendo los dominios más grandes o los dominios múltiples) . Típicamente, entre más grande el dominio del soporte de decisión, más óptima será la decisión. Consecuentemente, es deseable para el software de soporte de decisión el cubrir aún dominios más grandes en el proceso de realización de decisión. No obstante, esta ampliación de cobertura puede crear problemas significantes .

Un problema es el de eficientemente planear y administrar cadenas de suministro de dominios múltiples.

Típicamente, las cadenas de suministro de dominio múltiple son definidas manualmente y se administran en y en una manera ad hoc . Esto frecuentemente resulta en la omisión de componentes importantes de la cadena de suministro lo cual lleva a un volver a trabajar con tiempo consumido y costoso del plan de cadena de suministro entre los dominios múltiples involucrados en la cadena de suministro. Además, si la omisión no es detectada, las mefíciencias para la operación y administración del plan de cadena de suministro pueden resultar.

SÍNTESIS DE LA INVENCIÓN De acuerdo con la presente invención, un sistema y un método para administrar las colaboraciones dentro y entre las empresas se proporciona que elimina esencialmente o reduce las desventajas y problemas asociados con los sistemas y métodos previamente desarrollados. En particular, la presente invención proporciona un método implementado por computadora para administrar colaboraciones a través de nodos múltiples de una o más empresas .

De acuerdo a una incorporación de la presente mvencón, un proceso implementado por computadora para administrar un flujo de trabajo distribuido mlcuye el almacenar un juego de funciones predefinidas para un flujo de trabajo que van a ser llevadas a cabo en una pluralidad de nodos distribuidos. El proceso compuetadora automáticamente mteractúa con el flujo de trabajo en cada uno de los flujos de nodo distribuidos para llevar a cabo las funciones predefinidas.

Más específicamente, de acuerdo con un aspecto de la presente invención, un proceso implementado por computadora para diseñar y generar una colaboración entre una pluralidad de empresas incluye el recibir un diseño de colaboración preliminar de una primera empresa. El diseño de colaboración preliminar es transmitido automáticamente a una segunda empresa predefinida pra revisión. Una respuesta para el diseño de colaboración preliminar es recibido de una segunda empresa. La respuesta es recibida automáticamente a la primera empresa para la revisión.

De acuerdo a otro aspecto de la presente invención, un proceso implementado por computadora para desplegar una colaboración para una pluralidad de empresas ínlcuye el recibir micialmente una colaboración. Una primera parte predefinida de la colaboración es transmitida automáitcamente a una primera empresa predefinida. Una segunda parte predefinida de la colaboración es automáticamente transmitida a una segunda empresa predefinida para la operación.

De acuero con aún otro aspecto de la presente invención, un proceso implementado por computadora para seguir una colaboración a través de una pluralidad de empresas incluye el preguntar automáticamente a un primer nodo de una primera empresa respecto de un primer juego predefinido de datos asociados con la operación de la colaboración en el primer nodo. El primer juego de datos es transmitido automáticamente a un sistema de vigilancia. Un segundo nodo de una segunda empresa es preguntado automáticamente respecto de un segundo juego predefinido de información asociada con la operación de la colaboración en el segundo nodo El segundo juego de información es transmitido automáticamente al sistema de vigilancia.

Las ventajas técnicas de la presente invención incluyen el proporcionar un método y un sistema mejorado para administrar colaboraciones dentro de las empresas. En particular, las colaboraciones son definidas para generar, desplegar y vigilar otras colaboraciones a través de una pluralidad de nodos distribuidos Por tanto, las colaboraciones son manejadas eficientemente y predefinidas como para no omitir componentes esenciales.

Las ventajas técnicas adicionales deben ser fácilmente evidentes a un experto en el arte de las siguientes figuras, descripciones y reivindicaciones.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Un entendimiento más completo de la presente invención y de las ventajas de la misma puede adquirirse mediante el referirse a la siguiente discripción tomada en conjunción con los di ujos acompañantes en los cuales los números de referencia indican características de referencia, y en donde: La figura 1 es un diagrama de incorporación de una arquitectura implementada por computadora que puede soportar la colaboración de empresas.

La figura 2 es un diagrama de una incorporación de componentes de un sistema de colaboración global; la figura 3 es un diagrama de un sistema de colaboración global de la figura 2 en donde ciertos elementos de software que tienen módulos particulares están resaltados; la figura i es un diagrama de bloque de una incorporación de un sistema que permite la colaboración dentro de empresas para la realización de decisiones óptima; la figura 5 es un diagrama de bloque de la incorporación del uso de un espacio de trabajo de colaboración global; la figura 6 es un diagrama de una incorporación de un ciclo de vida para una colaboración; la figura 7 es un diagrama de situaciones en donde el software común está presente en ambos lados de la relación y en donde no lo está; la figura 8 es un diagrama de bloque de una incorporación de una configuración de seguridad para un caso de eje a radio y de eje a red, la figura 9 es un diagrama de bloque de una incorporación de una configuración de seguridad para un caso de eje a eje; La figura 10 es un diagrama de una incorporación de el diseño de un flujo de trabajo de entre empresas que incluye la formación de parámetros sobre grupos; la figura 11 es un diagrama de una incorporación de la administración de cambio mediante el modificar un diseño de un flujo de trabajo; la figura 12 es un diagrama de una incorporación de la integración de un mundo de trabajo con el mundo exterior, la figura 13 es un diagrama de una incorporación de un flujo de datos que corre en un actividad única.

La figura 14 es un diagrama de una incorporación de el flujo de datos dividido a través de actividades múltiples la figura 15 es un diagrama de bloque de la incorporación de un modelo de datos común basado en el modelo de transformación, la figura 16 es un diagrama de una incorporación de una transformación directa, la figura 17 es un diagrama de una incorporación de niveles de acceso y de transformación diferentes. la figura 18 es un diagrama de una incorporación de la substitución de un motor de eje por un motor de radio dentro de una colaboración La figura 19 es un diagrama de flujo que ilustra un proceso implementado por computadora para generar una colaboración entre una pluralidad de empresas de acuerdo con una incorporación de la presente invención La figura 20 es un diagrama de flujo que ilustra un proceso implementado por computadora para desplegar una colaboración para una pluralidad de empresas de acuerdo con una incorporación de la presente invención, y La figura 21 es un diagrama de flujo que ilustra un proceso implementado por computadora para vigilar una colaboración a través de una pluralidad de empresas de acuerdo con una incorporación de la presente invención.

DESCRPCION DETALLADA DE LA INVENCIÓN La mejora de los procesos de soporte de decisión mvlucra la expansión para proporcionar un nivel de empresas y un soporte de decisión de nivel de empresas múltiples para la realización de decisiones óptimas. Técnicamente y conceptualmente, el proporcionar un soporte de decisión de nivel de empresas múltiples y de nivel de empresa difiere del proporcionar soporte de decisión de nivel de fábrica y de nivel de cadena de suministro. Las razones para ésto pueden ser que, en las situaciones de dominios múltiples (tal como unidades de negocios dentro de una empresa o empresas múltiples) , los diferentes dominios frecuentemente operan diferente software de soporte de decisión. También, en las situaciones de dominios múltiples, un dominio generalmente no puede obligar a otro dominio a ser una decisión en particular. En otras palabras, el soporte de decisión óptima en este ambiente frecuentemente requiere el ser llevado a cabo en un ambiente negociado en oposición a uno coercitivo.

El proporcionar un soporte de decisión en situaciones de dominio múltiples que puede lograrse mediante el perseguir un acercamiento de colaboración para el soporte de decisión más bien que uno coercitivo. Varias tecnologías de procesamiento de comunicación y distribuidas pueden usarse para implementar tal ambiente, incluyendo el internet, la red, JAVA, XML, CORBA, etc., lo cual ayuda a ser posible una realización de decisión colaborativa a gran escala. Pronto estarán disponibles los productos de 12 TECHNOLOGIES que permitirán un acercamiento de colaboración al soporte de decisión, incluyendo el administrador de colaboración RHYTHM-GLOBAL (GCM) y el diseñador de colaboración RHYTHM-GLOBAL (GCD) .

Sistema de Colaboración y Componentes de Proceso La figura 1 es un diagrama de una incorporación de una arquitectura implementada por computadora que puede soportar la colabración de empresa. Como se mostró, una arquitectura de soporte de decisión global puede ser construida sobre el enlace subyacente, la mensajería global, la visión y los componentes de almacén de información. La colaboración puede entonces involucrar un diseñador de colaboración global (GCD) y un administrador de colaboración global (GCM) soportado por la arquitectura de soporte de decisión. El diseñador de colaboración global puede ser usado para diseñar e mstanciar colaboraciones, y el administrador de colaboración global puede ser usado para correr las colaboraciones. En este esquema, las colaboraciones pueden ser mencionadas como módulos y pueden tener versiones .

La figura 2 es un diagrama de una incorporación de componentes de un sistema de colaboración global. Como se mostró, el sistema puede permitir que colabore un eje de empresa 2 con una empresa radio 4 y una empresa red 6. La empresa eje 2 y la empresa radio 4 cada una incluyen un administrador de colaboración global 8. Los administradores de colaboración global 8 están acoplados a y se comunican con los espacios de trabajo de comunicación global internos respectivos 10. Un espacio de trabajo de colaboración global externa 12 proporciona unos medios para compartir información entre la empresa eje 2 , la empresa radio 2 y la empresa red 6. La empresa e e 2 tmbién puede colaborar a través de un procesador de intercambio de datos electrónico (EDI) 14 con un red agregada de valor (VAN) . Además, la empresa e e 2 puede comunicarse y colaborar con otras empresas eje usando un bus de mensaje global 15.

En operación, el controlador primario de la colaboración puede ser el motor de espacio de trabajo de colaboración global 8 de la empresa eje 2. La relación de e e a e e puede ser facilitada por el bus de mensaje global 15, y las relaciones de eje a radio y de eje a red pueden ser facilitadas por el espacio de trabajo de colaboración global externa (GCW) 12. Como se mostró, una empresa eje 2 puede generalmente tener un espacio de trabajo de colaboración global 10 y un espacio de trabajo de colaboración global externo 12. El espacio de trabajo de colaboración global interno 10 puede ser usado para compartir e intercambiar datos con las mterconecciones de usuario internas así como con el procesador de intercambio de datos electrónico 14. El espacio de trabajo de colaboración global 12 puede ser usado para compartir e intercambiar datos con las empresas radio 4 y las empresas red.

Por seguridad, el espacio de trabajo de colaboración global externo 12 puede ser instalado en un DMZ o afuera de una pared de incendio corporativa de una empresa eje 2. De esta manera no necesitan hacerse conecciones directas desde el exterior a la red corporativa protegida de la empresa eje 2. El espacio de trabajo de colaboración global puede aceptar por ejemplo, las conecciones II0P,HTTP, y HRRPS . En particular las últimas dos conecciones son útiles para hecer puente entre configuraciones de pared de incencdios existentes. De esta manera, no es necesaria una configuración de pared de incendios sobre cualesquier el cliente (nodo de radio o nodo de eje) o el servidor (nodo eje) lo cual puede hacer la solución más rápidamente despelgable .

La figura 3 es un diagrama de sistema de colaboración global de la figura 2 donde ciertos elementos de software que constituyen los módulos particulares están resaltados. Como puede verse, el software para el módulo de administrador de colaboración global puede estar presente en los siguientes lugares: en el motor de eje 8, en el motor de radio 8, en la mterconección de usuario de eje-usuario (VI), en la mterconección de usuario radio-usuario y en la mterconección de usuario de eje-nodo. Adicionalmente, el módulo puede comunicarse con las aplicaciones nativas 17 sobre la empresa eje 2 y la empresa radio 4. Las comunicaciones con las aplicaciones nativa 17 pueden ser ya sea sincrónicas (línea de punto) o asincrónicas (líneas sólidas) . La comunicación asincrónica con las aplicaciones nativas 17 puede ser facilitada por el espacio de trabajo de colaboración global interno 10, como se mostró, además, una base de datos de serie global (GSDB) puede estar presente sobre el lado empresa eje 2.

La figura 4 es un diagrama de bloque de un sistema indicado generalmente en el punto 16, que permite la colaboración dentro y entre las empresas para una realizarción de decisión óptima. Como se mostró, un sistema 16 incluye un nodo de e e 8 el cual puede ser un proceso dentro de un motor de eje que ejecuta sobre un sistema de computadora. El nodo de eje 18 está acoplado a y se comunica con un nodo de radio 20 el cua] también puede ser un proceso dentro de un motor de e e que se ejecuta sobre un sistema de computadora. Como se mostró, el nodo de radio 20 puede estar afuera de un límite de empresa 22 de el nodo de eje 18. El nodo de eje 18 también puede ser acoplado a y comunicarse con una pluralidad de nodos de radio 24 los cuales pueden ser procesos dentro de un motor de radio que ejecuta en uno o más sistemas de computadora. El nodo de eje 18 puede además estar acoplado a y comunicarse con una pluralidad de nodos de red 26 los cuales pueden ser procesados dentro de un explorador de red ejecutando sobre un sistema de computadora. Además el nodo de e e 18 está acoplado a y se comunica con el sustituto EDI (Intercambio de Datos Electrónicos) 28 el cual puede propircionar una compuerta a los sistemas de intercambio de datos electrónico.

Los motores de eje y los motores de radio junto con un espacio de trabajo de comunicación global, pueden ser las entidades primarias de un administrador de colaboración global. En este ambiente, un motor de eje es el controlador primario de la colaboración. El motor de e e puede coordinar a ambas la colaboración global así como las colaboraciones locales. Las colaboraciones globales son aquellas que abarcan nodos de eje 18, los nodos de radio 20 y 24 y los nodos de red 26. Un colaboración local puede correr sobre un eje de papel único o un grupo de radio/radio. Estas colaboraciones pueden ser distribuidas, pero permanecer dentro de una empresa única. Los motores de eje también pueden ser coordinados con mterconecciones de usuario y eje (Ul) así como el procesador de red de valor agregado-intercambio de datos electrónico de un sustituto de datos electrónico 28. En una incorporación, los motores de eje son motores de hilado múltiple que pueden coordinar simultáneamente colaboraciones múltiples así como versiones múltiples de la misma colaboración. Además, los motores de eje pueden cargar dinámicamente y ejecutar colaboraciones.

Un motor de radio puede también operar para iniciar una colaboración. En este ambiente, a diferencia de un motor de eje, un motor de radio no es una entidad independiente. En vez de ésto un motor de radio puede solo coordinar en conjunción con un motor de eje. Además, un motor de radio no puede coordinar con otros motores de radio u otros nodos de eje. Como un motor de eje, un motor de radio puede ser de hilados múltiples y puede coordinar simultáneamente colaboraciones múltiples así como versiones múltiples de la misma colaboración. Los motores de radio también pueden ser cargados dinámicamente y ejecutar colaboraciones.

La figura 5 es un diagrama de bloque de una incorporación del uso de un espacio de trabajo de colaboración global 30. En la figura 5, el espacio de trabajo de colaboración global 30 proporciona la entidad primaria usada para compartir datos/objetos entre las entidades en la colaboración. Como se mostró el espacio de trabajo 30 puede mterconectar con los administradores de colaboración global (GCMs) 32, un sistema local 34, un servidor de red 36 y una mterconección de red 37 yt las aplicaciones nativas 38. En general, los objetos pueden ser colocado en el espacio de trabajo de colaboración global 30 por una entidad y ser recurperados por otra entidad. La recuperación puede ser lograda ya se amediante pregunta o mediante suscripción. De esta manera, el espacio de colaboración global 30 con¿mbma los atributos de una base de datos así como de un bus de mensaje.

El espacio de trabajo de colaboración global puede ser organizada como una jerarquía de ranuras las cuales pueden estar en memoria o ser persistente. Las ranuras también pueden ponerse en cola o ser regulares, y los permisos de gran o fino pueden ser sujetado a cada ranura. Los permisos pueden ser signados por ususatio por operación. Las operaciones primarias pueden ser leer, escribir, tomar y suscribir.

Las ranuras en memoria retienen datos en la memoria volátil. La escritura y la recuperación de las ranuras en memoria es muy rápida pero se somete a la pérdida si el espacio de trabajo de colaboración global 30 se cae. Cuando se usa en las ranuras de memoria, el espacio de trabajo de colaboración global 30 puede ser sonsiderado una base de datos de objeto en memoria segura y rápida, con capacidades de seguridad y mensajería. Las ranuras persistentes retienen sus datos en una almacén estable. La escritura y la recuperación de las ranuras persisntes es más lenta que para las ranuras en memoria, pero los datos no se pierden si se cae el espacio de trabajo de elaboración global 30.

La decisión en cuanto a usar las ranuras en memoria o persistente puede depender de la aplicación. El espacio de trabajo de colaborción global 30 almacena los datos en la forma de objetos y puede almacenar objetos JAVA, objetos CORBA o un arreglo de BITE arbitrario, esto, acoplado con sus capacidades en memoria, hace al espacio de trabajo de colaboración global 30 apropiado como un mecanismo de compartir datos de alta velocidad entre otros motores en memoria orientados por objeto tal como el planeador de fábrica y el planeador de cadena de suministro de 12 TECHNOLOGIES .

Un diseñador de colaboración global (GCD) proporciona una herramienta para permitir a los diseñadores de colaboración el diseñar interactivamente, el istanciar y el desplegar colaboraciones que van a correrse usando el administrador de colaboración global. La salida del diseñador de colaboración global es un código que puede ser cargado automáticamente y ser corrido por el administrado de colaboración global. El diseñador de colaboración global puede permitir a los diseñadores el crear nuevas colaboraciones, recuperar colaboraciones existentes y colaboraciones de versión. El diseñador de colaboración global también puede permitir a los diseñadores el diseñar la red de eje y de radio para colaboraciones y diseño de los eventos y mensajes de la colaboración. El diseñador de colaboración global puede integrar una biblioteca de objeto estándar y una biblioteca de componente estándar para un uso fácil desde dentro del diseño de colaboración global . El diseñador de colaboración global puede ser usado para crear flujos de trabajo de empresas múltiples sofisticados con sincronía a sincronía, su flujo de trabajo y divisiones o -divisiones, uniones-sincronización, divisiones-heterofundido, uniones-heterofundido, etc. Los flujos de trabajo globales y los flujos de trabajo locales pueden ambos ser creados. El diseñador de colaboración global puede proporcionar una verificación automática de las colaboraciones y la generación de código automático, cuyo código se corre por el administrador de colaboración global. El código generado puede ser editado manualmente si se desea. Además, el diseñador de colaboración global puede proporcionar la iniciación de una colaboración que incluye la generación de configuraciones de administrador de seguridad y configuraciones de espacio de trabajo de colaboración global .

La figura 6 es un diagrama de una incorporación de ciclo de vida para una colaboración. Como se mostró, en el paso, una colaboración puede ser diseñada usando el diseñador de colaborción global. Entonces, en el paso 46, una colaboración puede ser mstanciada usando el diseñador de colaboración global. La colaboración mstanciada puede ser entonces desplegada, en el pso 44, usando el diseñador de colaboración global y el administrador de colaboración global. Después del desplegado, la colaboración puede ser corrida usando el administrador de colaboración global en el paso 46. Subsecuentemente, una nueva instancia puede ser creada o una nueva versión de la colaboración puede ser creada. Para crear una nueva instancia, el flujo regresa al paso 4 . Para una nueva versión, el diseñador de colaboración global puede ser usado en el paso 48 para modificar la colaboración.

La extensión del soporte de decisión de dominio único a el soporte de dominio múltiple puede ser complicado. En particular, la discusión siguiente describe un número de desafíos presentados por el soporte de decisión de dominios múltiples y las incorporaciones de cómo estos desafíos son examinados por el sistema presente en los procesos que permiten la colaboración dentro y entre las empresas para una realización de decisión óptima.

Heterogeneidad de la Representación Un problema con la colaboración es el puentear la heterogeneidad representacional a través de empresas. Antes de que pueda ocurrir exitosamente la colaboración, la heterogeneidad representacional a través de las empresas debe ser puenteada. Las empresas frecuentemente representan los mismos datos en maeras diferentes. Estas diferencias varían de diferencias semánticas a diferencias tecnológicas, a diferencias en nombres, etc. la solución obvia para puentear estas diferencias es la estandarización Sin embargo, esto inmediatamente eleva el asunto sobre qué estándar debe convenirse. El presente sistema y el proceso evitan tal requerimiento.

Deberá notarse que puede haber tres categorías relevantes de estándar que requieren ser examinados . Estas tres categorías son: estandars de formato, estandards de transporte y estandards semánticos. Los estandards de formato de refieren a los formatos tecnológicos los cuales los datos/objetos son codificados. Los ejemplos incluyen XML, las corrientes de la serie Java, las corrientes de la serie IIOP y el formato de intercambio de datos electrónico. Los estandars de transporte son usados para pasar datos, estos pueden incluir HTTP, IIOP, RMI , DCOM, FTP, las redes de valor agregado, los buses de mensaje asincrónico tal como MQSepes, etc. En tercer lugar los estándares semánticos son la forma en la cual el contenido «semántico de los datos está descrito. Los ejemplos incluyen el intercambio de dtos electrónico, el modelo de datos común 12 (CDM) .

Mediante el considerar los estándares en esta luz, puede surgir un entendimiento de los asuntos . Una mayoría de la confusión actual surge del hecho de que existen muchos estándares que cubren dos o más de las categorías arriba mencionadas y esas discusiones de los varios estándares falla en categopzar cual categoría está siendo discutida. Por ejemplo, el intercambio de datos electrónico es primariamente un estándar semántico, pero también típicamente implica un estándar de formato ( el formato de expediente de intercambio de datos electrónicos) y un transporte (una red agregada de valor) . Una vez que ésto es entendido, se hace claro que el estándar semántico de intercambio de datos electrónico puede ser separado de los otros dos. Por tanto, los objetos de intercambio de datos electrónico semántico puede ser codificado en otros formatos como las corrientes de seire Java y pueden pasarse sobre otros estándares de transporte tal como HTTP. Similarmente, XML es primariamente un estándar de formato que puede ser usado para codificar varios estándares semánticos. Están realizándose esfuerzos para codificar el intercambio de datos electrónico en XML.

Varios estándares de formato pueden ser soportados por el administrador de colaboración global presente, incluyendo XML el formato de intercambio de datos electrónico, las corrientes de serie Java (mencioandas como formato Java y no deben confundirse con el lenguaje Java o la plataforma Java) y las corrientes de serie IIOP. De éstos, en una incorporación, el formato Java es el formato primario y el resto son formatos derivados . Debido a que el formato Java puede contener el comportamiento para producir los otros formatos, se ha escogido como el formato primario. Los formatos XML, de intercambio de datos electrónico e IIOP pueden ser derivados del formato Java.

La figura 7 es un diagrama de situaciones en donde el software común de 12 TECHNOLOGIES está presente sobre ambos lados de una relación y en donde no lo está. Como se mostró, por ejemplo, cuando el administro de comunicación global RHYTHM está sobre ambos lados nada va a ganarse par convertir a un formato intermedio. Esto introducirá una meficiencia innecesaria, y sólo datos (no objetos) serían intercambiables limitando el rango de aplicaciones. Por tanto cuando el mismo software está presente sobre ambos lados, los objetos javabmarios pueden ser directamente intercambiados. Por otro lado, por ejemplo, cuando el ADMINISTRADOR DE COLABORACIÓN GLOBAL RHYTHM está presente sólo de un lado, los objetos formateados EDI o XML pueden ser producidos (salida) e interpretados (entrada) .

Con respecto a los estándares de transporte, el administrador de colaboración global presente puede soportar a la variedad de estandards de trasnporte, incluyendo HTTP, IIOP, y los buses de mensaje asincrónico. Mayores detalles se proporcionan abajo con respecto a manejar múltiples tipos de relación.

Con respecto a los estándares semánticos, el administrador de colaboración global presente puede primariamente soportar dos estándares semánticos e intercambio de datos electrónico y RHYTHM-CDM. El intercambio de datos electrónico puede ser soportado debido a que este es generalmente el estandard semántico más popular. Sin embargo este sufre de la desventaja (entre otras) de no porporcionar cobertura profunda del dominio de planeación. El RHYTHM-CDM, por otro lado, proporciona la cobertura profunda del dominio de planeación y proporcionará construcciones apropiadas para llevar a cabo un soporte de decisión de empresas múltiples. Adicionalmente, este formato está soportado por todos los motores de planeación de 12 TECHNOLOGIES.

En general, un problema con los estándares públicos, tal como el de intercambio de datos electrónico, es el de que estos no pueden cubrir adecuadamente las clases de datos/objetos que las empresas desearían intercambiar. Además, el esperar que los cuerpos de estándares se estandaricen sobre un objeto particular puede no ser una opción, y una cadena de suministro no tendrá ninguna ventaja competitiva particular mediante el usar estándares públicos. Por estas y otras razones, el administrador de colaboración global presente soporta un acercamiento alterno a la estandarización mediante el soportar estándares de comunidad propietarios. Por ejemplo, usando el RHYTHM-GCD, una comunidad de empresas puede diseñar un juego de estándares que son relevantes a sólo esa comunidad. El RHYTHM-GCM soportará y hará cumplir estos estándares de comunidad propietarios. El RHYTHM-GCD también sostiene una biblioteca de objetos de bloque de construcción que pueden estar compuestos en estándares de comunidad propietarios. Los estándares de comunidad propietarios tiene un número de avances, incluyendo: éstos pueden ser diseñados para cubrir exactamente las clases de datos/objetos que las empresas desearían intercambiar; sólo las partes relevantes requieren el estar de acuerdo sobre el estándar particular, por tanto el proceso será más rápido que el esperar por un cuerpo estándar; los diferentes estándares pueden ser desarrollados para diferentes categorías de socios y, en el caso extremo, un estándar diferente para cada socio; y pueden ser desarrollados estándares que dan a la cadena de suministro una ventaja competitiva sobre los competidores.

Tipos de Relaciones Múltiples Otro problema para permitir la colaboración es el manejo de tipos de relación múltiples. Las empresas tienen relaciones de varios tipos con sus socios. Algunas formas de relaciones que pueden variar son: entre los socios de comercio principales por un lado y entre los socios de comercio menores por el otro; entre las empresas de aproximadamente una igual influencia sobre la cadena de suministro y entre empresas de influencia desigual sobre la cadena de suministro, y entre las empresas con un alto grado de sofistificación tecnológica por el otro lado y entre empresas con un grado desigual de sofistificación tecnológica por el otro. Como deberá entenderse, éstos tipos de relaciones diferentes deben ser manejados en forma diferente.

El presente administrador de colaboración global puede modelar las relaciones de empresas como una red de eje y radio, como se describió arriba y se muestra en la Figura 4. En ésta incorporación, los cuatro tipos de relaciones son de e e a red; de eje a -VAN-intercambio de datos electrónico; de eje a radio y de e e a eje. Cada tipo de relación tiene su uso apropiado.

Con respecto al eje a red, cuando la gente habla hoy de "E-Comercio" , frecuentemente implican una arquitectura en donde el explorador de la red habla a algún servidor centralizado. Esta arquitectura tiene algunas ventajas: la infraestructura para el soporte de esta arquitectura está ya típicamente en el lugar; y toda la administración puede ser centralizada sobre el lado del servidor. Sin embargo, esta arquitectura también tiene una gran desventaja en el sentido de que requiere la presencia de un humano sobre el lado del explorador de la red. Por tanto, la automatización de sistema a sistema no es posible. Basándose sobre éstas ventajas y desventajas, éste tipo de relación puede apreciarse cuando una empresa requiere el intercambiar información con ya sea un socio menor o un socio con menos sofisticación tecnológica.

Con respecto a eje-a-VAN-intercambio de datos electrónicos, la gran mayoría del comercio entre empresas electrónico tiene lugar hoy por medio de enviar intercambio de datos electrónicos sobre redes de valor agregado. La ventaja de éste acercamiento puede ser que la integración de sistema a sistema sea posible y que esté sostenida actualmente el día de hoy. Las desventajas de este acercamiento son: los grandes costos para enviar datos sobre VAN's propietarias; los altos costos administrativos altos debido a la falta de una verdadera estandarización; el requerimiento de herramientas de terceras personas justo para convertir del verdadero "estándar" a una forma apropiada para la empresa; no hay soporte para la integración de sistema-a-humano; y no hay soporte para estándares propietarios o estándares corporativos. Basándose sobre estas y otras ventajas y desventajas, este tipo de relación puede ser apropiado cuando se soporta un ambiente de legado VAN-intercambio de datos electrónico.

Con respecto al eje-a-radio, éste tipo de relación también permite una integración de sistema a sistema como el VAN-íntercambio de datos electrónico. Arquitectónicamente el eje a radio es una colaboración entre un motor de e e y un motor de radio. La relación de eje a radio puede tener las ventajas de VAN-intercambio de datos electrónico; ésta puede usar el Internet público para reducir los costos de red; los costos administrativos son mucho más bajos que los de VAN- intercambio de datos eletrónico debido a que una gran parte de la infraestructura de red de e e a radio puede mostrarse centralmente y ser administrada; los verdaderos objetos (en adición a sólo la información) pueden ser intercambiados permitiendo mucho más avanzadas colaboraciones; y los estándares semánticos múltiples pueden ser soportados incluyendo el intercambio de datos electrónico, 12 -modelo de datos común y los estándares de comunidad propietaria. Basándose sobre las características arriba mencionadas, la relación de eje a radio puede ser apropiada cuando las empresas que desean llevar a cabo una colaboración de sistema a sistema sofisticada. También puede ser apropiado en donde no está presente un programa de software de 12 Technologies en cualesquiera de las empresas. Esto se debe a la relación de eje a radio que puede ser desplegada centralmente por la empresa de eje.

Con respecto al eje a eje, la relación es similar a la de eje a radio excepto porque ésta tiene lugar entre los dos motores de e e más bien que un motor de eje y uno de radio. Basándose sobre esta característica, la relación de eje a eje puede ser apropiada entre empresas que desean el llevar a cabo una colaboración de sistema a sistema sofisticada. Además, la relación de e e a e e puede ser apropiada cuando dos empresas tienen un RHYTHM-GCM comprado separadamente y han puesto sus motores de eje.

Hay diferencias entre los motores de e e y los motores de radio. En general, unas capacidades de motores de eje son sobrepuestas de unas capacidades de motor de radio. La siguiente Tabla proporciona un ejemplo de algunas de las diferencias .

TABLA 1 Seguridad Un problema adicional con una colaboración es el desafío de proporcionar una seguridad comprensiva. Antes de que las empresas puedan colaborar efectivamente, necesita examinarse el asunto de la seguridad. Puede haber muchas facetas diferentes para la seguridad en un contexto de colaboración. Un cuadro de colaboración de empresas múltiples cualesquiera debe de referirse a todas éstas facetas diferentes. Los requerimiento para una red de seguridad colaborativa puede incluir que: intercambio de datos entre los dos socios deba ser sólo visto por los dos socios; que los datos intercambiados entre los dos socios deban ser a prueba de invasión; una empresa debe ser capaz de verificar que un socio es quien dice que lo sea; el cuadro no debe introducir nuevos agujeros de segundad en la red de los socios; y el cuadro debe ser relativamente fácil de poner y de administrar.

Un cuadro de colaboración de seguridad puede ser proporcionado mediante el implementar una estrategia de segundad comprensiva para referirse a los requerimientos arriba mencionados. En una incorporación, la estrategia tiene tres aspectos diferentes para esto: seguridad tecnológica, una permisibilidad de cuadro y división de datos.

La seguridad tecnológica puede referirse a los medios tecnológicos usados para garantizar la seguridad. Esta seguridad puede ser usada para proporcionar: ppvacía, verificación, e integridad de información. La privacía asegura que ninguna persona no autorizada pueda ver los datos. La autenticación involucra el autenticar que las partes en la colaboración son realmente quienes ellos reclaman ser. La integridad de datos involucra el hacer imposible para una persona no autorizada el modificar los datos que están siendo enviados en cualesquier forma.

El acercamiento de segundad preciso puede variar basándose sobre el tipo de relación descrito anteriormente. Por ejemplo, un esquema está detallado en la Tabla que sigue abajo: TABLA Como puede verse de la Tabla, todos los tipos de relación, con la excepción de el eje-a-VAN EDI, pueden soportar la segundad desde SSL 3.0.

El SSL 3.0 es un protocolo estándar de industria usado para soportar la codificación clave pública sobre una conexión de base de socket y proporciona: privacía, certificación de cliente así como de servidor, integridad de datos y manejo certificado. El SSL 3.0 es un protocolo de nivel superior en el cual vanos algoritmos criptográficos de clave pública pueden ser conectados incluyendo RSA y Diffíe-Helman.

Una vez que el saludo SSL es completado, el siguiente paso es la autenticación de la palabra clave del nombre del usuario. Esto proporciona una certificación más allá de lo que proporciona el SSL 3.0 mismo. Las claves pueden ser almacenadas usando codificación a base de palabras clave PKCS5 (una norma RSA) . Una vez que un usuario o radio es certificado, éste se regresa a una muestra de acceso. Esta muestra de acceso tiene una vida de tiempo especificable por el administrador. Un usuario puede entonces tener acceso al sistema por la duración de la validez de la muestra de acceso. Esto tiene el efecto benéfico de no requerir certificación para cada acceso. Cada aplicación la cual es accesada, certifica la muestra de acceso mediante la validación de la firma (la cual es un resumen codificado usando la clave privada del administrador de seguridad) del administrador de dicha seguridad.

El cuadro de seguridad tecnológica es una parte del esquema de seguridad. La otra parte tiene que ver con el diseño de las colaboraciones mismas. El cuadro debe permitir a las empresas el dar fácilmente permisos a vanas acciones que otras empresas pueden llevar a cabo. El espacio de trabajo de colaboración global puede soportar un modelo de permiso jerárquico con los permisos individuales unidos a diferentes elementos de datos en la jerarquía. En particular, éste puede soportar permisos de leer, escribir, tomar y suscribir de usuario específico y de hablante específico. Por tanto, las empresas pueden afinar detalladamente quién puede leer y qué datos, quién puede escribir qué datos, quién puede tomar qué datos y quién puede suscribir para escribir notificaciones sobre qué datos.

Un tercer elemento en la estrategia de segundad del cuadro de colaboración es la capacidad de que la división de datos a través de varios espacios de trabajo de colaboración. En particular, los espacios de trabajo colaboradores son divididos en un espacio de trabajo colaborador interno y un espacio de trabajo colaborador externo. Sólo los datos que requieren el ser verdaderamente compartidos con los socios están en el espacio de trabajo colaborador externo. El resto está en el espacio de trabajo colaborador interno. El espacio de trabajo colaborador externo está diseñado para asentarse ya sea afuera de la pared de fuego corporativa o en una extrared o DMZ. El diseño de armazón de colaboración no requiere el espacio de trabajo colaborador externo para hacer decisiones a través de la pared de fuego corporativa en el Intranet (aún cuando lo podría hacer) .

En una incorporación, las colaboraciones globales pueden usar ambos los espacios de trabajo colaboradores externo e interno. Las colaboraciones locales pueden usar sólo el espacio de trabajo colaborador interno y son por tanto invisibles a las empresas socias. Aún para los colaboraciones globales sólo las partes relevantes usan el espacio de trabajo colaborador externo. Además, debido al armazón de trabajo de permisibilidad descrito anteriormente, cada empresa socia puede sólo ver (leer, escribir, tomar, suscribir) sus propios datos.

La Figura 8 es un diagrama de bloque de una incorporación de una configuración de seguridad para un caso de eje a radio y de eje a red. Como se mostró, una empresa eje 50 está acoplada a y se comunica con un espacio de trabajo de colaboración global interno 52 y un espacio de trabajo de colaboración global externo 54. Una empresa radio 56 y una empresa red 58 se conectan a través de un servidor de red 60 a un espacio de trabajo de colaboración global externo 5 . La empresa red 56, como la empresa e e 50, tiene un espacio de trabajo de colaboración global interno 62. Las empresas 50, 56 y 58 pueden ser protegidas por las paredes de fuego asociadas, mientras que la extrared formada por el servidor de red 60 y el espacio de trabajo de colaboración global externo 54 pueden ser protegidos por un director de filtrado y la comunicación a través de HTTP sobre SSL 3.0.

La Figura 9 es un diagrama de bloque de una incorporación de una configuración de seguridad para un caso de eje a eje. Como se mostró, una empresa de eje 64 y una empresa de eje 66 pueden comunicarse a través de una conexión TCP/IP protegida SSL 3.0. La comunicación puede ser entre los agentes de mensaje globales separados 68 y 69. Ambas empresas de eje 64 y 66 están protegidas por una pared de fuego, como se mostró.

Fluí os de Trábalo Entre Empresas Uno de los problemas con el soporte de decisiones de empresas múltiples puede ser que no haya una colaboración de circuito cerrado. En vez de esto, los datos pueden ser lanzados de una empresa a la siguiente sin un flujo de trabajo coherente. A fin de implementar una colaboración de circuito cerrado, es necesario el soporte para crear flujos de trabajo de empresas múltiples. El presente administrador y diseñador de colaboración global hace posible el construir, desplegar, vigilar y cambiar flujos de trabajo de empresas múltiples sofisticadas.

En general, un "flujo de trabajo" puede ser un juego de "actividades" unidas juntas por flujos de datos que juntos logran alguna tarea. Los flujos de trabajo son ejecutados típicamente sobre motores de flujo de trabajo. Un "flujo de trabajo distribuido" puede referirse a un flujo de trabajo que es ejecutado sobre motores de flujo de trabajo múltiples. En otras palabras, las diferentes partes del flujo de trabajo se ejecutan sobre máquinas o motores diferentes. Un "nodo" puede referirse a las entidades abstractas sobre las cuales corren diferentes motores de flujo de trabajo de una corrida de flujo de trabajo distribuida y un "grupo nodo" puede ser un juego de nodos agrupados por algunas características. Un "flujo de trabajo distribuido de empresas múltiples" puede ser flujos de trabajo distribuidos en donde los nodos son empresas.

La parameterización de los flujos de trabajo puede ser importante para la colaboración de las empresas. Un "flujo de trabajo paramétrico" es un flujo de trabajo que está parametepzado sobre vanas variables y puede ser regular o distribuido. El instanciar el flujo de trabajo paramétpco con diferentes valores de las variables de parámetro produce diferentes instancias del flujo de trabajo. Un "flujo de trabajo distribuido parametizado sobre nodos en un grupo nodo" puede referirse a flujos de trabajo distribuidos en donde los parámetros del flujo de trabajo son los nodos en un grupo nodo. Por tanto, cuando el flujo de trabajo es instanciado éste es confeccionado para un nodo particular en un grupo nodo.

Hay vanas características importantes para los flujos de trabajo que puedan ser soportados por la colaboración global presente. Estos flujos de trabajo pueden ser tipificados fuertemente. La tipificación fuerte ser esencial para producir flujos de trabajo libres de error y robustos. En esencia, la tipificación fuerte garantiza el tipo de un mensaje en un tiempo de diseño Por ejemplo, si el flujo de trabajo está diseñado para enviar una cuenta de materiales, entonces la tipificación fuerte asegura que sea físicamente imposible el que un objeto distinto a una cuenta de materiales se envíe. Para un flujo de trabajo diseñado con el diseñador de colaboración global y ejecutado con el administrador de colaboración global, éste puede hacer imposible el aún enviar un objeto de un tipo incorrecto. Esta capacidad es importante para producir flujos de trabajo libres de error y robustos.

A pesar de la tipificación fuerte hay, por ejemplo, dos escenarios en los cuales los tipos de objetos incorrectos serían concebiblemente pasados en el flujo de trabajo: debido a un error de la parte del diseñador del flujo de trabajo; y a un intento malicioso de alguien para perjudicar el flujo de trabajo. Ambos de éstos escenarios pueden ser manejados. El primero puede ser manejado mediante el hacer imposible que un error en diseño lleve a tal escenario. El segundo puede ser manejado mediante el hacer que los datos fluyan a prueba de violación mediante el usar una codificación clave pública u otro esquema de codificación (integridad característica) como se describió arriba.

Otra característica importante es el soporte para los flujos de trabajo parametepzados sobre los grupos. Algunos flujos de trabajo de empresas múltiples involucran un gran número de empresas. En tales casos, sería impráctico el crear flujos de trabajo individualizados para cada socio. En vez de ésto puede ser ventajoso el crear flujos de trabajo que sean parameterizados sobre grupos de socios. Por ejemplo, en el campo de la procuración, dos grupos pueden ser los proveedores primarios y los proveedores secundarios . El grupo proveedor primario puede tener un tipo de flujo de trabajo y el grupo de proveedores secundarios pueden tener otro tipo de flujo de trabajo. Los flujos de trabajo a base de grupos pueden ser paramétricos en el sentido de que al tiempo corrido, un flujo de trabajo actual puede ser creado específico para un miembro de un grupo.

En el contexto de empresas múltiples, una empresa puede colaborar, por ejemplo, con cientos o miles potencialmente de otras empresas. Cada colaboración o flujo de trabajo de empresas múltiples puede ser potencialmente (y típicamente) único. Sin embargo, el diseño de cientos o miles de flujo de trabajo especializados con socios de empresas ni es deseable ni posible. Por otro lado, muchos de estos flujos de trabajo son simplemente variaciones paramétricas sobre un flujo de trabajo parametepzado subyacente. Por ejemplo, una compañía A puede ser colaboradora (en las ventas) con los detallistas, distribuidores, ventas directas etc. Por tanto, hace sentido el agrupar los varios socios. Un agrupamiento de ejemplo puede ser: WalMart, Sears; el resto de los detallistas además de WalMart y de Sears (grupo) , distribuidores primarios (grupo) y distribuidores secundarios (grupo) . Ahora, los flujos de trabajo con todos los miembros, por ejemplo, del grupo de distribuidores primarios son variaciones sobre un flujo de trabajo distribuido paramétpco subyacente, parametepzado sobre el distribuidor particular en ese grupo.

Los flujos de trabajo parametepzados sobre grupos pueden soportarse mediante una técnica de definición de flujo de trabajo de HETEROCASTING. La técnica de definición HETEROCASTING generalmente involucra el usar una definición de flujo de trabajo con parámetros para iniciar flujo de trabajo heterogéneos basados sobre diferencias en los parámetros. Por tanto, la técnica de definición HETEROCASTING permite un flujo de trabajo distribuido no en parámetros para ser fácilmente hecho (a través de una herramienta de diseño visual) con parámetros sobre nodos en un grupo de nodo. Puede haber dos actividades de flujo de trabajo primarias usadas para lograr esta definición: una actividad dividida HETEROCAST y una actividad unida HETEROCAST. Todas las actividades entre dividido HETEROCAST y la unión HETEROCAST son puestas en parámetros sobre los nodos de un grupo de nodo a los que corresponden estas actividades.

La Figura 10 es un diagrama de una incorporación del diseño de un flujo de trabajo entre empresas que incluye el poner parámetros sobre grupos. Como se mostró, el flujo de trabajo puede comenzar con una actividad de escucha 70 que espera algún evento. La actividad 70 puede ser enlazada a las actividades paralelas 71 que enlazan a un sub-flujo de trabajo 72 y a una división de HETEROCAST 73. El sub-flujo de trabajo mismo puede incluir una definición de flujo de trabajo. Con respecto a HETEROCASTING, el flujo de trabajo después de la división HETEROCAST 73 se hace con parámetros. Por tanto, en el ejemplo de la Figura 10, la actividad 74 es una actividad con parámetros. Después de la actividad 74, un HETEROCAST unido 75 recibe el flujo de la actividad 74. El sub-flujo de trabajo 72 y el HETEROCAST unido 75 son enlazados a una unión sincrónica o asincrónica 76 la cual, a su vez, enlaza a un evento integrado 77 (por ejemplo, multireparto) . Un tipo de flujo de trabajo de la Figura 10 puede ser diseñado usando el diseñador de colaboración global presente y puede permitir una representación completa del flujo de trabajo para el soporte de decisión entre empresas. Este flujo de trabajo puede entonces ser mstanciado e implementado a través del administrador de colaboración global presente.

La Figura 11 es un diagrama de una incorporación del cambio de administración mediante el modificar un diseño de un flujo de trabajo. Como se mostró, un diseño de flujo de trabajo inicial puede tener un evento 70 enlazado a una división de actividad paralela 71. Entre al división de actividad 71 y una unión 76 puede haber por ejemplo, dos actividades 78. Este flujo de trabajo, una vez diseñado, puede ser instanciado e implementado usando el administrador de colaboración global. Si requiere hacerse un cambio al flujo de trabajo, el diseñador de colaboración global alivia grandemente el problema de hacer el cambio. Por ejemplo, una nueva actividad 79 puede ser agregada entre la división 71 y la unión 76. El flujo de trabajo puede entonces ser reinstanciado e implementado centralmente.

En particular, la técnica HETEROCAST puede permitir la construcción de flujos de trabajo distribuidos y con parámetros sobre nodos en un grupo de nodo. Esto puede permitir una ganancia de productividad enorme sobre el diseño de flujos de trabajo individuales para miembros de grupos individuales. Además, esta técnica hace un diseño rápido y un prototipo de flujos de trabajo de entre empresas sofisticados con cientos o miles de socios posibles. La técnica debe ser distinguida del "multireparto" convencional en el cual mensajes idénticos son enviados a los varios nodos (socios) . En esencia, el multireparto permite a una persona el diseñar un flujo de trabajo único que corre idénticamente a través de nodos múltiples. Esto difiere de la técnica HETEROCASTING, en donde los flujos de trabajo corren diferentemente basándose sobre qué nodo está siendo corriendo.

Una tercera característica importante es el soporte para los flujos de trabajo a base de reparto. Los flujos de trabajo basados en el reparto permiten que dichos flujos de trabajo sean usados específicamente para repartos genéricos.

Esta capacidad permite la creación de flujos de trabajo genéricos o templados que pueden ser mstanciados en vanos escenarios. Por ejemplo, los tipos de papeles o reparto pueden ser: papeles de socios, papeles de ejes; papeles de grupo de radio; papeles de red; papeles de grupo de red; papeles de usuario. Como un ejemplo de los papeles o repartos, los papeles de socios se refieren a los diferentes papeles o caracteres jugados por los socios. Por tanto, un papel de socio en el caso de la procuración es el de proveedor primario y de proveedor secundario.

Los flujos de trabajo a base de reparto pueden llevar al concepto de tres diferentes fases en el diseño y ejecución de un flujo de trabajo. La fase de diseño es la fase en la cual los flujos de trabajo a base de reparto son definidos. La fase de la instancia es la fase en la cual los repartos son mapeados a instancias. Por ejemplo, el proveedor primario puede ser mapeado para una primera compañía, y el aprobador_PO puede ser mapeado a John Doe . En tercer lugar, la fase de tiempo de corrida puede ser la fase en la cual el flujo de trabajo en instancia corre.

Una característica importante adicional es la integración de flujos de trabajo automatizados con flujos de trabajo orientados por el usuario. Los flujos de trabajo pueden frecuentemente ser descritos como que tienen dos variedades: los flujos de trabajo de sistema a sistema automatizados, y los flujos de trabajo de interconexión de usuario. Aún cuando hay flujos de trabajo que son completamente automatizados, hay flujos de trabajo que son completamente impulsados por el usuario, la mayoría de los flujos de trabajo tienen elementos de interconexión automatizados así como de interconexión de usuario. La colaboración global presente de administrador y diseñador no requiere el hacer esta distinción artificial entre los tipos de flujo de trabajo. Por tanto, los flujos de trabajo pueden ser automatizados en partes e interactuar con los usuarios en otras partes. Ambas las partes automatizadas y las partes de usuario pueden abarcar empresas múltiples.

Integración con el Mundo Exterior La Figura 12 es un diagrama de una incorporación de la integración de un flujo de trabajo con el mundo exterior. Como se describió en la sección previa, pueden ser creados flujos de trabajo entre empresas y dentro de las empresas. Estos flujos de trabajo pueden estar compuestos de actividades atadas juntas en vanas configuraciones. No hay una restricción sobre qué diferentes actividades del flujo de trabajo pueden hacerlo sin embargo una de las tareas principales de estas actividades es la de integrarse con el mundo exterior. La figura 12 muestra cómo un flujo de trabajo puede ser integrado con el mundo exterior usando un acercamiento a base de componente para la integración.

Los componentes pueden incluir accesores 80, transformaciones 82, objetos de transerencia 84, adaptadores y flujos 86.

El administrador de colaboración global puede soportar un modelo de integración a base de componente El modelo de integración a base de componente permite la flexibilidad en la estructuración de la integración. Puede haber dos tipos de componentes: componentes primitivos y componentes compuestos. Los componentes primitivos pueden incluir accesores 80, los transformadores 82 y los objetos de transferencia 84. Los componentes compuestos incluyen adaptadores y flujos 86 Los componentes compuestos son construidos en términos de componentes primitivos. En este esquema, los accesores 80 son usados para tener acceso a una fuente externa tal como SCP (planeador de cadena de suministro) , SAP, una base de datos de relación, servidores de red, e-correo electrónico, buses de mensaje, etcétera. Los accesores 80 pueden ser usados para leer, escribir o escuchar fuentes y destinos de datos. Los transformadors 82 pueden ser usados para transformar los datos de una forma a otra forma. Los objetos de transferencia 84 son objetos que pueden ser pasados de una actividad a actividad o de empresa a empresa. Los objetos de transferencia 84 pueden ser opcionalmente convertidos a estructuras EDI, XML, CORBA, etcétera. Los accesores 80 y los transformadores 82 pueden ser atados juntos para formar flujos. Un flujo completo puede ser ejecutado en una actividad única como se mostró en la Figura 13.

La Figura 13 es un diagrama de una incorporación de un flujo de datos que corre en una actividad única 92. Como se mostró, una fuente de datos 90 puede ser accesible desde y proporcionar datos a un componente de accesor 94. El componente accesor 94 entonces puede pasar datos a través de los componentes de transformador 96 y 98 los cuales proporcionan datos a un segundo componente accesor 100. Los datos pueden entonces ser almacenados en un destino de datos 102.

La figura 14 es un diagrama de una incorporación de una división de flujo de datos a través de actividades múltiples 104 y 106. Como se mostró, el flujo de la figura 14 difiere de aquel de la figura 13 en el sentido de que los componentes de transformador 96 y 98 están dentro de actividades separadas 104 y 106 y se comunican con un objeto de transferencia. Los flujos de datos de empresas múltiples pueden estar basados sobre el modelo de la figura 14 más bien que aquel de la figura 13.

Con respecto a las transformaciones, en una incorporación, pueden soportarse dos tipos de transformación fundamentales: las transformaciones a base de 12 -CDM y las transformaciones directas. Las transformaciones a base de I2-CDM son a base del MODELO DE DATOS COMÚN DE 12 TECHNOLOGIES (CDM) . El modelo de datos común es un esquema disponible en ambas formas de relación y de objeto.

La Figura 15 es un diagrama de bloque de una incorporación de un modelo de transformación a base de I -CDM. Como se mostró, los transformadores y los accesores pueden ser acoplados para transformar una aplicación de datos en un objeto de datos CDM 110 y viceversa. Por ejemplo, un objeto de planificador de cadena de suministro (SCP) 112 puede ser creado por un accesor de planeador de cadena de suministro desde los datos de planeador de cadena de suministro 114. El objeto de planeador de cadena de suministro 112 puede entonces ser transformado por un transformador de planeador de cadena de suminñistro-CDM en un objeto de CDM 110. Análogamente, un objeto de SAP 116 puede ser creado por un accesor SAP de los datos SAP 118. El objeto SAP 116 puede entonces ser transformado por un transformador SAP-CDM en un objeto CDM 110. El accesor SAP y el transformador, como con otros accesorios y transformadores puede ser combinado en un adaptador SAP-CDM estándar 120 que puede ser usado para transformaciones a base de CDM y otros componentes . Como otro ejemplo, un objeto VAAN 122 puede ser creado por un accesor VAAN desde unos datos VAAN 124. El objeto VAAN 122 puede entonces ser transformado en un objeto de modelos de dato común 110 por un transformador VAAN-CDM. Estas transformaciones trabajan en otra dirección también.

La figura 16 es un diagrama de una incorporación de una transformación directa En los transformadores directos, los objetos son convertidos de una forma a otra sin pasar a través de un formato intermedio. Por ejemplo, como se mostró en la figura 16, los datos de planeador de cadena de suministro (SCP) 130 pueden ser accesados por un accesor SCP para crear un objeto SCP 132. El objeto de planeador de cadena de suministro 132 puede entonces ser transformado directamente en un objeto de planeador de fábrica (FP) 134. El objeto de planeador de fábpa 134 puede entonces convertirse en datos de planeador de fábrica 136 a través de un accesor de planeador de fábrica. Este flujo de datos puede operar en otra dirección también.

En estos procesos, hay varios niveles de granulación a los cuales el acceso y la transformación puede tomar lugar incluyendo la relación (tabla) , el objeto genérico (árbol, gráfica, matriz, etcétera) y el objeto específico (cuenta de material, plan, etcétera) a niveles. Algunas veces el acceso puede solo ser disponible en un nivel (dígase tabla) pero la transformación puede ser más apropiada a otro nivel (dígase objeto genérico) . Por ejemplo, el agregado jerárquico (una forma de transformación) es frecuentemente apropiada sobre un objeto de árbol. Sin embargo, los datos pueden solo ser accesibles en una forma tabular. En este caso, por ejemplo, los datos deben ser accesados al nivel tabular, transformarse en un árbol, y entonces tener aplicado a éste el agregado jerárquico.

La figura 17 es un diagrama de una incorporación de diferentes niveles de acceso y de transformación. Como se mostró, el acceso y la transformación pueden tener tres niveles. Un primer nivel 140 puede involucrar las transformaciones y acceso a la tabla. Un segundo nivel 142 puede involucrar un acceso y transformaciones de objeto genérico (árbol, gráfica, etcétera) y un tercer nivel puede involucrar un acceso de objeto específico (construcción de materiales, plan, etcétera) , y transformaciones. Además de las transformaciones entre los formatos de aplicación, también puede haber transformaciones entre tres niveles como se mostró.

Desarrollo de Colaboraciones Un importante factor en un sistema de colaboración de empresas múltiples es la facilidad con la cual puede desplegarse la colaboración. Como se discutió, el administrador de colaboración global presente puede soportar cuatro clases diferentes de relaciones de socio: de eje a red, de eje a radio, de eje a eje, y de eje a VAN-EDI . De estos cuatro, el eje a red tiene todas las características de desplegado de las aplicaciones de red tradicionales. El eje-a-VAN EDI pueden desplegarse a la extensión de que ésta nivela una infraestructura VAN-EDI existente. Aún cuando la relación de eje a red es altamente desplegable, ésta puede sufrir del problema de requerir un humano en el lado de red de la relación. En otras palabras, puede no ser adecuada para una colaboración de sistema a sistema.

La solución de eje a radio puede proporcionar un despliegue máximo en el ambiente de colaboración de sistema a sistema. En el realmo de eje a radio, el motor de radio es análogo al explorador de red, y la parte de radio de la colaboración es análoga a una página de red. En forma similar a la página de red, la parte de radio de la colaboración puede ser diseñada centralmente y desplegada a los motores de radio remotos. A diferencia de la página de red, puede haber aún integración que requiera hacerse remotamente. Esta integración remota puede ser inevitable pero puede ser circunscrita y definida precisamente por la parte de red de la colaboración.

Otro aspecto del despliegue es el manejo de versiones. Las colaboraciones una vez diseñadas y desplegadas son factibles de que requieran cambio (en vanas diferentes maneras) al progresar el tiempo. Puede ser importante el que subsecuentes versiones de colaboraciones sean fácilmente desplegables como las versiones iniciales. El administrdor de colaboración global presente puede proporcionar un soporte completo para las versiones y el redespliegue centralizado de las colaboraciones. Además, las diferentes versiones de las colaboraciones pueden correr simultáneamente sin impactarse unas a otras Esto permite que una versión existente sea faseada graciosamente fuera mientras que otra versión esté faseada adentro .

Otro elemento del despliegue del presente administrador de colaboración global es el nivel de infraestructura existente. Este elemento es evidente, por ejemplo, en el soporte de la relación de eje a radio sobre los protocolos de red existentes. El soporte de eje a radio sobre los protocolos de red existentes puede ser importante para un despliegue rápido ya que no se requiere la modificación o la reconfiguración de una infraestructura de red existente. Los ahorros de tiempo grandes en este aspecto pueden venir de no tener que modificar cuidadosamente la pared de fuego diseñada y las infraestructuras de segundad que pueden ya estar en el lugar.

Soporte de Colaboraciones de Muchos-a-Muchos La presente arquitectura de radio a eje proporciona una administración y despliegue fácil. Sin embargo, en la práctica las empresas colaboran con muchas empresas las cuales a su vez colaboran con aún otras empresas. Por tanto, las empresas frecuentemente forman una gráfica o red colaboradora. Esto puede soportarse a través de la capacidad de sustituir un motor de eje por un motor de radio en cualquier momento. Esta capacidad de sustitución permite a las redes de colaboración de muchas a muchas el ser cultivadas orgánicamente más bien que todas a la vez.

La Figura 18 es un diagrama de una incorporación de la sustitución de un motor de red por un motor de radio dentro de una colaboración. Como se mostró, una empresa (El) puede desplegar un motor de eje 150 sobre sí misma y un motor de radio 152 en todos los sitios de socios. En particular, un motor de radio 154 puede ser un sitio de socio (E2) . Si el sitio de socio (E2) desea el diseñar y controlar su propia colaboración, éste puede reemplazar el motor de radio 154 con un motor de eje 156. Desde la perspectiva de El, E2 puede aún ser un radio en la colaboración de la El. Sin embargo, este radio ahora corre sobre un motor de eje 156 el cual puede controlar sus propias colaboraciones con los motores de radio 158. Además, los motores de radio 160 y 162 pueden estar asociados con una tercera entidad (E3) que mteractúa con ambos el motor de cubo 150 y el motor de eje 156 a nombre de la empresa E3.

Extensión del Armazón de Trabajo Un aspecto importante del presente armazón de trabajo es su extensión. Sin la extensión, el armazón de trabajo puede no ser capaz de manejar nuevas situaciones y desafíos que confronte. Puede haber vanas dimensiones diferentes para ésta extensión. Por ejemplo, un área primaria de extensión está en el área de las normas de objeto semántico. Si los estándares soportados no son suficientes para un problema particular, entonces el armazón de trabajo puede ser aumentado con nuevos estándares semánticos. Adicionalmente, el armazón de trabajo permite la construcción de estándares semánticos propietarios. Además, el armazón de trabajo puede ser extendido mediante el agregar nuevos accesores, transformadores, adaptadores, etc. La biblioteca de componente estándar puede extenderse ambos generalmente y por los usuarios finales.

Administración de Colaboración La presente invención maneja las colaboraciones dentro y entre las empresas. Descrito generalmente, la presente invención proporciona un proceso implementado por computadora para manejar flujos de trabajo y colaboraciones distribuidas entre nodos de una o más empresas . El proceso implementado por computadora maneja una colaboración para almacenar un juego de funciones predefinidas para que se lleve a cabo la colaboración y los nodos distribuidos. El proceso implementado por computadora automáticamente mteractúa con la colaboración de cada uno de los nodos para llevar a cabo las funciones predefinidas. Como se usó aquí, cada uno significa que cada uno de por lo menos un subjuego de los artículos identificados. El proceso implemetnado por computdora puede ser una colaboración de alto nivel generada y procesada por el diseñador de colaboración global y el administrador de colaboración global como se describió previamente en conexión con otras colaboraciones del sistema u otros procesos adecuados capaces de manejar una colaboración a través de nodos múltiples. Las funciones predefinidas pueden ser funciones para generar, desplegar, vigilar o de otra manera mteractuar con una colaboración.

La figura 19 ilustra un diagrama de flujo para generar una colaboración entre una pluralidad de empresas de acuerdo con una incorporación de la presente invención. Refiriéndonos a la figura 19, el método para generar una colaboración comienza en el paso 160 en el cual una colaboración preliminar es recibida de una primera empresa. La colaboración es preliminar en el sentido de que ésta puede ser comentada sobre o modificada por otras empresas involucradas en la colaboración. La colaboración preliminar puede ser generada o de otra manera proprocionada por la primera empresa.

Precediendo al paso 162, la colaboración preliminar es transmitida automáticamente a una segunda empresa involucrada en la colaboración. La colaboración preliminar puede ser transmitida a un eje, un radio o a otro nodo adecuado de la segunda empresa. Como se usó aquí, un evento es automático en el sentido de que el evento es predefinido y llevado a cabo por el proceso de computadora. El evento puede ser inmediato o en respuesta a la acción del usuario u otro evento adecuado.

En el paso 164, una respuesta a la colaboración preliminar es recibida de la segunda empresa. La respuesta puede ser un comentario a la colaboración preliminar, una modificación de la colaboración preliminar, y similares. Una modificación a la colaboración preliminar puede ser una modificación de o en adición a la colaboración preliminar. El tipo de respuesta permitible puede ser controlada por privilegios concedidos a la segunda empresa.

Después en el paso 166, la respuesta es transmitida automáticamente a la primera empresa la cual lleva a el fin del proceso. En la misma manera en la que la colaboración preliminar es transmitida a la segunda empresa y una respuesta es transmitida desde la segunda empresa, la colaboración preliminar puede ser transmitida a cualesquier número de otras empresas y las respuestas recibidas de aquellas empresas. Las diferentes empresas pueden ser concedidas diferentes privilegios para modificar o meramente comentar sobre la colaboración preliminar. Esta revisión y respuesta por todas o un número de las empresas involucradas lleva a una colaboración final que se ha considerado cuidadoamente por y es optimizada por las empresas involucradas.

Además de involucrar una pluralidad de empresas en el diseño de la colaboración, el proceso de diseño puede ser subdividido en una pluralidad de fases. Por ejemplo, en una primera fase, un número seleccionado de empresas puede dejarse el modificar una colaboración preliminar. Después de que aquellas empresas han accedido a una colaboración basada sobre la colaboración preliminar y las modificaciones subsecuentes a la colaboración preliminar, la colaboración resultante puede entonces ser transmitida a otras empresas involucradas para el comentario u otra respuesta limitada.

En otra incorporación, el diseño de colaboración puede ser separado en rangos generales y específicos. En esta incorporación, la colaboración preliminar es un delineado para una colaboración entre las empresas. Después de que el delineado de la colaboración se ha acordado entre las empresas involucradas, los detalles específicos de la colaboración pueden ser transmitidos y respondidos entre las empresas. En esta manera, las colaboraciones son generadas eficientemente dentro y entre los nodos distribuidos de una o más empresas.

La figura 20 ilustra un diagrama de flujo para desplegar una colaboración generada por una primera empresa para una pluralidad de otras empresas de acuerdo con una incorporación de la presente invención. Refiriéndonos a la figura 20, el método comienza en el paso 170 en el cual una colaboración es generada por una primera empresa. Después, en el paso 172, una primera parte predefinida de la colaboración es trasmitida a una segunda empresa para la operación. La primera parte de la colaboración es transmitida a un radio u otro nodo adecuado de la segunda empresa.

Procediendo al paso 174, una segunda parte predefinida de la colaboración es automáticamente transmitida a una tercera empresa para la operación. La segunda parte de la colaboración es transmitida a un radio u otro nodo adecuado para la tercera empresa. En esta manera misma, otras partes de la colaboración pueden ser transmitidas automáticamente a otras empresas para la operación. En esta manera, la colaboración es desplegada dentro o entre las empresas con una interacción de usuario mínima.

En una incorporación, la colaboración es desplegada pero no corrida por cualquiera de las empresas hasta que todas o un número suficiente de las empresas han aprobado la colaboración. En esta manera, el proceso puede individualmente solicitar y recibir aprobaciones de las empresas involucradas. En esta forma, la colaboración no es corrida prematuramente para solo una o unas pocas de las empresas si la operación de las versiones más viejas de las colaboraciones no son terminadas prematuramente .

La figura 21 ilustra un método para vigilar una colaboración a través de una pluralidad de empresas de acuerdo con una incorporación de la presente invención. Refiriéndonos a la figura 21, el método comienza en el paso 180 en el cual un primer nodo es preguntado respecto de los datos asociados con la operación de una colaboración en un primer nodo. La pregunta puede ser llevada a cabo por un agente u otro mecanismo adecuado. Preferiblemente, el agente opera en un primer nodo para minimizar el uso de los recursos de red.

Procediendo al paso 182, los datos del primer nodo son transmitidos automáticamente a un sistema de vigilancia. La transmisión de los datos puede ser periódica o en respuesta a un evento predefinido. El sistema de vigilancia puede ser en un eje, un radio u otro nodo adecuado o del sistema.

En el paso 184, un segundo nodo es cuestionado por los datos asociados con la operación de la colaboración en el segundo nodo. Como se describió previamente en relación con el primer nodo, el cuestionamiento puede llevarse a cabo por un agente local En el paso 186, los datos del segundo nodo son transmitidos automáticamente al sistema de vigilancia. La operación de la colaboración en los nodos adicionales puede ser vigilada similarmente . En esta manera la operación de la colaboración a través de un número de empresas puede ser vigilada o seguida, en un nodo, en una ubicación central o ser vigilada individualmente por las empresas involucradas .

Aún cuando la presente invención se ha descrito en detalle, deberá entenderse el que varios cambios, sustituciones y alteraciones pueden hacerse a la misma sin departir del espíritu y del alcance de la invención como se define en las reivindicaciones anexas.

Claims (20)

R E I V I N D I C A C I O N E S

1. Un proceso implementado por computadora para administrar y distribuir flujo de trabajo que comprende: almacenar un juego de funciones predefinidas para un flujo de trabajo que va a llevarse a cabo en una pluralidad de nodos distribuidos; mteractuar automáticamente con el flujo de trabajo en cada uno de los nodos distribuidos para llevar a cabo las funciones predefinidas.

2. El proceso, tal y como se reivindica en la cláusula 1, caracterizado porque el juego de funciones predefinidas son operables para generar un flujo de trabajo entre una pluralidad de empresas.

3. El proceso, tal y como se reivindica en la cláusula 1, caracterizado porque el juego de funciones predefinidas son operables para transmitir datos asociados con la operación del flujo de trabajo en cada uno de los nodos distribuidos para un sistema de vigilancia.

4. El proceso, tal y como se reivindica en la cláusula 1, caracterizado porque el juego de funciones predefinidas son operables para desplegar el flujo de trabajo a los nodos distribuidos.

5. Un proceso implementado por computadora para generar una colaboración entre una pluralidad de empresas que comprende : recibir una colaboración preliminar desde una primera empresa; transmitir automáticamente la colaboración preliminar a una segunda empresa predefinida para revisión; recibir una respuesta para la colaboración de la segunda empresa; y transmitir automáticamente la respuesta a la primer empresa para revisión.

6. El proceso, tal y como se reivindica en la cláusula 5, caracterizado porque la respuesta es un comentario al a colaboración preliminar.

7. El proceso, tal y como se reivindica en la cláusula 5, caracterizado porque la respuesta es una modificación de la colaboración preliminar.

8. El proceso, tal y como se reivindica en la cláusula 7, caracterizado porque la modificación es en adición a la colaboración preliminar.

9. El proceso, tal y como se reivindica en la cláusula 7, caracterizado porque la modificación es una modificación a la colaboración preliminar.

10. El proceso, tal y como se reivindica en la cláusula 5, caracterizado además porque comprende: recibir una aprobación de las empresas primera y segunda para una colaboración basada sobre la colaboración preliminar y la respuesta; transmitir automáticamente la colaboración a una tercera empresa predefinida para revisión; recibir una respuesta para la colaboración de la tercera empresa; y automáticamente transmitir la respuesta a la primera empresa para revisión.

11. El proceso, tal y como se reivindica en la cláusula 10, caracterizado porque la respuesta es un comentario.

12. El proceso, tal y como se reivindica en la cláusula 10, caracterizado porque la respuesta es una modificación a la colaboración.

13. El proceso, tal y como se reivindica en la cláusula 12, caracterizado porque la modificación es una adición a la colaboración.

14. El proceso, tal y como se reivindica en la cláusula 12, caracterizado porque la modificación es una modificación de la colaboración.

15. Un proceso implementado por computadora para desplegar una colaboración generada por una primera empresa para una pluralidad de otras empresas que comprende: recibir una colaboración; transmitir automáticamente una primera parte predefinida de la colaboración a una segunda empresa predefinida; y automáticamente transmitir una segunda parte predefinida de la colaboración a una tercera empresa predefinida.

16. El proceso, tal y como se reivindica en la cláusula 15, caracterizado además porque comprende: solicitar una aprobación de la segunda empresa para la operación de la primera parte de la colaboración en un nodo de la segunda empresa; y solicitar una aprobación para la tercera empresa para la operación de la segunda parte de al colaboración en un nodo de la tercera empresa.

17. El proceso, tal y como se reivindica en la cláusula 16, caracterizado porque en respuesta a recibir la aprobación de la segunda empresa, notificar a la tercera empresa de la aprobación.

18. El proceso, tal y como se reivindica en la cláusula 16, caracterizado porque en respuesta a recibir las aprobaciones de la segunda y tercera empresas transmitir una señal a las empresas segunda y tercera para operar la colaboración.

19. El proceso, tal y como se reivindica en la cláusula 16, caracterizado porque en respuesta a recibir aprobación para operar la colaboración de todas las empresas a las cuales la colaboración es transmitida, transmitir una señal a todas las empresas para operar la colaboración.

20. Un proceso implementado por computadora para vigilar una cíolaboración a través de una pluralidad de empresas que comprende : automáticamente cuestionar un primer nodo de una primera empresa respecto de un primer juego predefinido de datos asociado con la operación de la colaboración en el primer nodo; transmitir el primer juego de datos a un sistema de vigilancia; automáticamente preguntar a un segundo nodo de una segunda empresa por un segundo juego predefinido de datos asociados con una operación de la colaboración en el segundo nodo; y transmitir el segundo juego de datos al sistema de vigilancia. R E S U E N Se proporciona un proceso implementado por computadora para la colaboración de empresas. El proceso incluye el almacenar un juego de funciones predefinidas para un flujo de trabajo que va a llevarse a cabo en una pluralidad de nodos distribuidos. El proceso automáticamente interactúa con el flujo de trabajo en cada uno de los nodos distribuidos para llevar a cabo las funciones predefinidas.