miércoles, 8 de abril de 2009

VISION DE SERVICIO FUNCIONAL Y COMERCIAL

La arquitectura funcional que soporta la visión, es decir, que en esta solución las órdenes de compra son generadas por el personal del Departamento y enviadas posteriormente al servidor departamental en el cual se ejecutan las aplicaciones de compras y facturación.

Son necesarios los siguientes servicios EDI:

* Comunicación externa;

* Traductor para codificar/decodificar la información local en mensajes normalizados EDIfact;

* Comunicación interna: el sistema departamental proporciona las capacidades necesarias para importar/exportar datos entre el traductor y la base de datos local;

* Servicios de seguridad para garantizar la autenticidad e integridad en las transacciones de órdenes de compra y facturas

* Servicios de gestión: histórico de los mensajes enviados/recibidos, informes de error e informes de estado del sistema. La pasarela EDI puede también residir en otro sistema, por ejemplo, una estación de trabajo EDI dedicada.

Visión Comercial

El escenario mostrado en la Figura I-2 abarca negocios multilaterales y multisectoriales en los que la Administración Pública juega diferentes papeles: contratista de un proceso cliente/servidor, fuente de información estadística, etc. Además, se requieren distintos acuerdos de intercambio para cubrir los diferentes escenarios EDI entre socios comerciales.

Algunos requisitos destacados que tiene que reunir esta solución son:

* Algunas transacciones, como las órdenes de pago, tienen que ser seguras;

* para el almacenamiento y administración de los datos más relevantes de las organizaciones comerciales (nombre y dirección) y sus perfiles de cooperación, puede utilizarse un directorio distribuido;

* Para soportar de forma segura (fiable) las transacciones de órdenes de pago un notario electrónico debe actuar como proveedor de un servicio de certificación o registro notarial;

* Los mensajes recibidos tienen que ser reconocidos (mediante el acuse de recibo).

Integración y Migración

Existen dos soluciones básicas para integrar un paquete de software EDI dentro del entorno tecnológico:

* Solución de Procesador Front-End -frontal de comunicaciones- (FEP): los servicios EDI se mantienen tan separados como sea posible de las aplicaciones existentes;

* Solución Integrada: las aplicaciones existentes se modifican para integrar en ellas la funcionalidad EDI. La Solución 1 puede implementarse de dos formas:

* El paquete de software EDI reside en una máquina separada (frecuentemente un PC) que se conecta con el sistema de información del contratista por medio de un paquete simple de comunicaciones.

* El paquete de software EDI está corresidente con las aplicaciones del sistema de información de la Administración Pública.

Frecuentemente, la solución FEP sobre máquina separada es la opción favorita para introducir el EDI en grandes organizaciones durante proyectos pilotos/de prueba. En general es barato, permite una puesta en marcha rápida y no enlaza directamente el sistema de información del contratista con el mundo exterior. Esta solución tiene algunas desventajas: la conectividad entre el FEP y el sistema de información puede resultar difícil; si el FEP es un PC, debe tenerse en cuenta la dimensión de los recursos hardware; podrían ser necesarios servicios de seguridad que garanticen el enlace entre el FEP y las aplicaciones del usuario.

Sin embargo, está claro que en el futuro la funcionalidad EDI se integrará en el sistema de información .

No hay comentarios:

Publicar un comentario