Alexander Gusyatiner, Oleg Zhikharev

INTRODUCTION

Cadre d'automatisation de l'expédition (SAF)

Sea-Freight Automation Foundation (SAF)

Version 0.2, 04 octobre 2018

Le modèle actuel de soutien de l'information pour les processus de transport peut être caractérisé comme suit:

Contrôle manuel des processus, exécution manuelle des tâches et ré-entrée des données.

La plupart des processus d'entreprise, y compris ceux qui se répètent régulièrement et ne nécessitent pas de décisions complexes, sont entièrement contrôlés et exécutés par des personnes. Dans le cadre de l'exécution de divers contrats logistiques, le personnel passe régulièrement des appels téléphoniques, utilise le courrier électronique, saisit à nouveau les données dans divers formulaires Web, suit les expéditions sur diverses plateformes en ligne, documente l'exécution des contrats, etc.

Grandes plates-formes monolithiques.

La plupart des systèmes de contrôle utilisés sont de grands monolithes difficiles à modifier qui limitent et rendent difficile l'adaptation aux nouvelles technologies et aux changements commerciaux.

Ces systèmes comprennent:

Plates - formes d'information : plates-formes d'expédition, plates-formes de guichet unique douanier, plates-formes de lignes de conteneurs, plates-formes ferroviaires, systèmes de gestion des terminaux maritimes (TOS), plates-formes de camionnage, systèmes de gestion portuaire, etc.

Plateformes d'intégration qui assurent l'interaction entre les systèmes de gestion et les clients individuels travaillant sur Internet: plates-formes d'intégration cloud commerciales, systèmes de communauté portuaire, systèmes de paiement électronique, etc.

Processus fragmentés.

Les processus métier sont divisés en fragments séparés et indépendants. Par exemple, le processus d'exportation de conteneur se produit dans les fragments suivants:

*           . *          . *         . 

Par conséquent, il n'est pas possible de retracer l'ensemble du processus de transport et les participants sont souvent tenus de ressaisir les données.

Diverses interfaces utilisateur.

Au cours d'une journée de travail normale, un utilisateur effectuant une tâche standard répétitive doit utiliser des plates-formes en ligne où cette tâche est effectuée de manières complètement différentes. Par exemple, pour les lignes de conteneurs, chaque système de gestion de terminaux a sa propre interface utilisateur pour réserver un conteneur sur un navire.

Absence de norme pour les rôles commerciaux, les accords et les transactions.

En conséquence, différents participants interagissent les uns avec les autres de différentes manières, leurs rôles ne sont pas clairement définis, les opérations commerciales (transactions) sont effectuées et documentées de différentes manières.

Manque d'API standard.

Les plates-formes d'information et d'intégration commerciale dans un seul but ont des capacités d'intégration différentes: elles prennent en charge des API non standard et utilisent divers formats de message, tels que: EDI, XML, fichiers de valeurs séparées par des virgules, Excel, etc.

Utilisation de divers protocoles Internet. \
La situation est compliquée par l'utilisation de différents protocoles d'échange de données sur Internet: FTP, Email, Services WEB, etc. \

Manque de services Internet pour un certain nombre de participants.

La plupart des lignes de conteneurs et des transitaires ont leurs propres sites Web avec divers services 24h / 24 et 7j / 7, mais la plupart des expéditeurs, transporteurs routiers, courtiers en douane n'ont pas une présence permanente sur Internet. Par conséquent, les appels téléphoniques, le courrier Internet et les réunions sont les principaux moyens de communication, et cette communication s'arrête souvent lorsque les participants sont inaccessibles.

Tous les facteurs ci-dessus entraînent les conséquences suivantes:

• Faible niveau d'automatisation des processus métier.
• Le coût élevé de la mise en œuvre et du support des plateformes.
• Coûts supplémentaires des participants au transport pour les services de diverses plateformes d'intégration commerciale.
• Les participants au transport sont confrontés à l'inaccessibilité, à l'opacité et à la difficulté d'obtenir des informations à différentes étapes du transport.

Le Maritime Automation Framework (SAF) est une initiative open source qui vise à accroître l'automatisation des processus en introduisant des rôles commerciaux, des accords, des transactions et des API standard.

Définitions et caractéristiques clés de SAF:

• Un participant (entreprise ou personne) possède un identifiant unique et joue un ou plusieurs rôles définis dans le SAF : exportateur, expéditeur, douanes, terminal maritime, port, ligne maritime, etc.
• Un accord (Engagement) est un accord formel ou informel entre les parties pour interagir pour atteindre un objectif commercial spécifique, par exemple:
• Transport du conteneur par mer du port de chargement au port de déchargement et son transfert au destinataire;
• Appel du navire au port;
• Enregistrement de la déclaration en douane d'exportation;
• Transport du conteneur de l'expéditeur au terminal maritime;
• Livraison du fret au destinataire depuis le terminal maritime;
• etc.
• Le processus électronique est un processus opérationnel pour la mise en œuvre de l' accord . Chaque processus électronique a son propre code unique. En règle générale, à la fin d'un tel processus, le paiement est effectué pour les services rendus.
• R-App est une application conçue pour automatiser un rôle spécifique. Chaque R-App appartient à un membre et possède un identifiant unique. L'ensemble du réseau SAF comprend de nombreuses applications de ce type.
• E-Chain est une chaîne temporaire composée d'applications R-App participant à un processus particulier ( E-Process ) .
• L' application R-App peut être mise en œuvre en tant que service cloud, application de bureau, application mobile pour smartphone, application de chaîne de blocs décentralisée (Dapp), etc.
• La R-App échange des messages entre eux via un appel de méthode à distance: le client R-App appelle la méthode dans le serveur R-App , lui envoie un message et reçoit un autre message en réponse.
• SAF-Transaction est un objet de données composé d'un message envoyé, d'un message (ou de messages) reçu en réponse, d'un nom de méthode et d'identifiants de participant.
• Le processus d'exécution de transaction ( SAF-Transaction) consiste à transférer des messages et à modifier l'état interne des participants à R-App .
• Le client et le serveur R-App écrivent les transactions ( SAF-Transaction ) qu'ils effectuent dans leurs propres bases de données.
• SAF décrit les API standard pour chaque application ( R-App ). L'API déclare les méthodes d'appel à distance, ainsi que les formats des messages envoyés et des messages reçus en réponse.
• R-App est constamment, 24/7, présenté sur Internet et enregistré dans les bureaux d'enregistrement en ligne ( Registre en ligne ).
• Les applications R-App peuvent participer simultanément à différents types de processus ( E-Process) et transférer des données d'un processus à un autre.
• R-App est engagé dans la surveillance automatique et le contrôle des processus ( E-Process ). En cas de retard, les applications peuvent contacter automatiquement les participants directement par SMS ou e-mail.
• SAF-Model est une description des rôles, conventions, transactions et API, réalisée en langage de description de données Proto 3.

L'utilisation de SAF peut conduire aux développements positifs suivants: