Alexander Gusyatiner, Oleg Zhikharev

INTRODUCCION

Marco de automatización de envíos (SAF)

Fundación para la automatización del transporte marítimo (SAF)

Versión 0.2, 04 de octubre de 2018

El modelo actual de soporte de información para procesos de transporte se puede caracterizar de la siguiente manera:

Control manual de procesos, ejecución manual de tareas y reingreso de datos.

La mayoría de los procesos de negocios, incluidos los que se repiten regularmente y no requieren decisiones complejas, están totalmente controlados y realizados por personas. En el proceso de cumplir con varios contratos de logística, el personal realiza llamadas telefónicas de forma rutinaria, utiliza el correo electrónico, vuelve a ingresar los datos en varios formularios web, rastrea los envíos en varias plataformas en línea, documenta la ejecución de los contratos, etc.

Grandes plataformas monolíticas.

La mayoría de los sistemas de control utilizados son monolitos grandes y difíciles de cambiar que limitan y dificultan la adaptación a las nuevas tecnologías y los cambios comerciales.

Dichos sistemas incluyen:

Plataformas de información : plataformas de embarque, plataformas de ventanilla única de aduanas, plataformas de línea de contenedores, plataformas de ferrocarril, sistemas de gestión de terminales marítimas (TOS), plataformas de camiones, sistemas de gestión de puertos, etc.

Plataformas de integración que proporcionan interacción entre los sistemas de gestión y los clientes individuales que trabajan en Internet: plataformas comerciales de integración en la nube, sistemas de la comunidad portuaria, sistemas de pago electrónico, etc.

Procesos fragmentados.

Los procesos comerciales se dividen en fragmentos separados y no relacionados. Por ejemplo, el proceso de exportación del contenedor ocurre en los siguientes fragmentos:

*           . *          . *         . 

Como resultado, no es posible rastrear todo el proceso de transporte y los participantes a menudo tienen que volver a ingresar los datos.

Diversas interfaces de usuario.

Durante un día laboral normal, un usuario que realiza una tarea estándar repetitiva tiene que usar plataformas en línea donde esta tarea se realiza de maneras completamente diferentes. Por ejemplo, para las líneas de contenedores, cada sistema de gestión de terminales tiene su propia interfaz de usuario para reservar un contenedor en un barco.

Falta de estándares para roles comerciales, acuerdos y transacciones.

Como resultado, diferentes participantes interactúan entre sí de diferentes maneras, sus roles no están claramente definidos, las operaciones comerciales (transacciones) se realizan y documentan de diferentes maneras.

Falta de API estándar.

Las plataformas de información y de integración comercial para un propósito tienen diferentes capacidades de integración: admiten API no estándar y utilizan varios formatos de mensajes, tales como: EDI, XML, archivos de valores separados por comas, Excel, etc.

Usando varios protocolos de Internet. \
La situación se complica por el uso de varios protocolos para el intercambio de datos en Internet: FTP, correo electrónico, servicios web, etc. \

Falta de servicios de Internet para varios participantes.

La mayoría de las líneas de contenedores y los transitarios tienen sus propios sitios web con varios servicios las 24 horas, los 7 días de la semana, pero la mayoría de los cargadores, transportistas por carretera y agentes de aduanas no tienen una presencia permanente en Internet. Como resultado, las llamadas telefónicas, el correo de Internet y las reuniones son los principales medios de comunicación, y esta comunicación a menudo se detiene cuando los participantes son inaccesibles.

Todos los factores anteriores conducen a las siguientes consecuencias:

• Bajo nivel de automatización de procesos de negocio.
• El alto costo de implementación y soporte de plataformas.
• Costos adicionales de los participantes del transporte por los servicios de varias plataformas de integración comercial.
• Los participantes del transporte se enfrentan a la inaccesibilidad, la opacidad y la dificultad de obtener información en varias etapas del transporte.

El Maritime Automation Framework (SAF) es una iniciativa de código abierto que busca aumentar la automatización de procesos mediante la introducción de roles comerciales estándar, acuerdos, transacciones y API.

Definiciones y características clave de SAF:

• Un participante (empresa o persona) tiene un identificador único y desempeña uno o varios roles definidos en el SAF : exportador, remitente, aduanas, terminal marítima, puerto, línea marítima, etc.
• Un acuerdo (Compromiso) es un acuerdo formal o informal entre las partes para interactuar para lograr un objetivo comercial específico, por ejemplo:
• Transporte del contenedor por mar desde el puerto de carga hasta el puerto de descarga y su traslado al destinatario;
• Llamada del buque al puerto;
• Registro de declaración de aduana de exportación;
• Transporte del contenedor desde el cargador hasta la terminal marítima;
• Entrega de carga al destinatario desde la terminal marítima;
• etc.
• E-Process es un proceso comercial para la implementación del Acuerdo . Cada E-Process tiene su propio código único. Como regla general, al final de dicho proceso, el pago se realiza por los servicios prestados.
• R-App es una aplicación diseñada para automatizar un rol específico. Cada R-App pertenece a un miembro y tiene un identificador único. Toda la red SAF consta de muchas de esas aplicaciones.
• E-Chain es una cadena temporal que consta de aplicaciones R-App que participan en un proceso particular ( E-Process ) .
• La aplicación R-App se puede implementar como un servicio en la nube, una aplicación de escritorio, una aplicación móvil para un teléfono inteligente, una aplicación de cadena de bloques descentralizada (Dapp), etc.
• La R-App intercambia mensajes entre sí a través de una llamada a un método remoto: la R-App del cliente llama al método en la R-App del servidor, le envía un mensaje y recibe otro mensaje en respuesta.
• SAF-Transaction es un objeto de datos que consiste en un mensaje enviado, un mensaje (o mensajes) recibidos en respuesta, un nombre de método e identificadores de participantes.
• El proceso de ejecución de la transacción ( SAF-Transaction) consiste en reenviar mensajes y cambiar el estado interno de los participantes de la R-App .
• El cliente y el servidor R-App escriben las transacciones ( SAF-Transaction ) que realizan en sus propias bases de datos.
• SAF describe las API estándar para cada aplicación ( R-App ). La API declara métodos para llamadas remotas, así como los formatos de mensajes enviados y mensajes recibidos en respuesta.
• R-App se presenta constantemente, 24/7, en Internet y se registra en registradores en línea ( Registro en línea ).
• Las aplicaciones R-App pueden participar simultáneamente en diferentes tipos de procesos ( E-Process) y transferir datos de un proceso a otro.
• R-App se dedica al monitoreo automático y control de procesos ( E-Process ). En caso de demoras, las aplicaciones pueden contactar automáticamente a los participantes directamente por SMS o correo electrónico.
• SAF-Model es una descripción de Roles, Convenciones, Transacciones y API, realizada en lenguaje de descripción de datos Proto 3.

El uso de SAF puede conducir a los siguientes desarrollos positivos: