Александр Гусятинер, Олег Жихарев

ВВЕДЕНИЕ

Фреймворк Автоматизации Морских Перевозок (SAF)

Sea-Freight Automation Foundation (SAF)

Версия 0.2, 04 Октября 2018

Текущая модель информационного сопровождения транспортных процессов может быть охарактеризована следующим образом:

Ручное управление процессами, ручное выполнение задач и повторный ввод данных.

Большинство бизнес-процессов, включая те процессы, которые повторяются регулярно и не требуют принятия сложных решений, полностью контролируются и выполняются людьми. В процессе выполнением различных логистических контрактов, персонал рутинно совершает телефонные звонки, пользуется электронной почтой, повторно вводит данные в различные веб-формы, отслеживает грузы в различных онлайн платформах, документирует выполнение договоров и так далее.

Большие Монолитные Платформы.

Большинство используемых систем управления являются большими, трудно изменяемыми монолитами, которые лимитируют и затрудняют адаптацию к новым технологиям и изменениям в бизнесе.

К таким системам относятся:

Информационные Платформы: платформы грузоотправителей, таможенные платформы (Customs Single Window), платформы контейнерных линий, платформы железных дорог, системы управления морскими терминалами (TOS), платформы автомобильных перевозчиков, системы управления портами и т.д.

Интеграционные Платформы, обеспечивающим взаимодействие систем управления и индивидуальных клиентов, работающих в Интернете: Коммерческие облачные интеграционные платформы, Системы портовых сообществ, Системы электронных платежей и т.д.

Фрагментированные Процессы.

Бизнес процессы разделены на отдельные, несвязанные между собой, фрагменты. Например, процесс контейнерного экспорта происходит в следующих фрагментах:

*   Оформление Экспортной Таможенной Декларации происходит на платформе экспортера и  платформе таможни. 
*   Резервирование контейнера происходит в пределах платформы грузоотправителя и контейнерной линии.
*   Букирование контейнера на судно происходит в Системе Управления Терминалом.

В результате отсутствует возможность проследить весь процесс перевозки и участники часто обязаны повторно вводить данные.

Разнотипные пользовательские интерфейсы.

В течение обычного рабочего дня пользователю, выполняющему повторяющуюся стандартную задачу, приходится использовать онлайн платформы, где эта задача выполняется совершенно по разному. Например, для контейнерных линий каждая Системе Управления Терминалом имеет свой пользовательский интерфейс для букирования контейнера на судно.

Отсутствие стандарта для бизнес ролей, соглашений и транзакций.

В результате, различные участники по разному взаимодействуют друг с другом, их роли четко не определены, бизнес-операции (транзакции) выполняются и документируются разными способами.

Отсутствие Стандартных API.

Информационные и коммерческие интеграционные платформы одного назначения имеют разные интеграционные возможности: они поддерживают нестандартные API и используют различные форматы сообщений, такие как: EDI, XML, comma-separated values files, Excel и т.д.

Использование различных Интернет протоколов.
Ситуация осложняется использованием различных протоколов для обмена данными в Интернете: FTP, Email, WEB Services и т.д.

Отсутствие Интернет сервисов для ряда участников.

Большинство контейнерных линий и экспедиторов имеют собственные интернет сайты с различными 24/7 сервисами, однако большинство грузоотправителей, автомобильных перевозчиков, таможенных брокеров не имеют постоянного присутствия в Интернете. В результате телефонные звонки, интернет-почта и совещания являются основными способами общения и это общение часто останавливается, когда участники оказывается недоступными.

Все вышеперечисленные факторы приводят к следующим последствиям:

• Низкий уровень автоматизации бизнес-процессов.
• Высокая стоимость внедрения и поддержки платформ.
• Дополнительные затраты участников перевозки на услуги различных коммерческих интеграционных платформ.
• Участники перевозки сталкиваются с недоступностью, непрозрачностью и сложностью получения информации на различных этапах перевозки.

Фреймворк Автоматизации Морских Перевозок (SAF) это опен-сорс инициатива, которая предусматривает увеличение автоматизации процессов путем внедрения стандарта бизнес ролей, соглашений, транзакции и API.

Основные определения и характеристики SAF:

• Участник (компания или человек) имеет уникальный идентификатор и играет одну или несколько ролей определенных вSAF: экспортер, грузоотправитель, таможня, морской терминал, порт, морская линия и т.д.
• Соглашение (Engagement) -это формальное или неформальная договоренность между участниками по взаимодействию для достижения определенной бизнес-цели, например:
• Транспортировка контейнера морем из порта погрузки в порт выгрузки и передача его грузополучателю;
• Заход судна в порт;
• Оформление экспортной таможенной декларации;
• Транспортировка контейнера от грузоотправителя в морской терминал;
• Доставка груза грузополучателю из морского терминала;
• и т.д.
• E-Process — это бизнес процесс по выполнению Соглашения. Каждый E-Process имеет свой уникальный код. Как правило, в конце такого процесса осуществляется оплата за выполненные услуги.
• R-App — это приложение, предназначенное для автоматизации определенной роли. Каждый R-App принадлежит одному участнику и имеет уникальный идентификатор. Вся сеть SAF состоит из множества таких приложений.
• E-Chain — это временная цепочка, состоящая из R-App приложений, принимающих участие в определенном процессе (E-Process).
• R-App приложение может быть выполнено в виде облачного сервиса, настольного приложения, мобильного приложения для смартфона, децентрализованного блокчейн приложения (Dapp) и т.д.
• R-App обмениваются сообщениями друг с другом посредством дистанционного вызова методов: клиентский R-App вызывает метод в серверном R-App, передает ему сообщение и получает в ответ другое сообщение.
• SAF-Transaction — это объект данных, состоящий из посланного сообщения, сообщения (или сообщений), полученного в ответ, названия метода и идентификаторов участников.
• Процесс выполнения транзакции (SAF-Transaction) состоит из пересылки сообщений и изменения внутреннего состояния R-App участников.
• Клиентская и серверная R-App записывают транзакции (SAF-Transaction),которые они выполняют, в собственные базы данных.
• SAF описывает стандартные API для каждого приложения (R-App). В API декларируются методы для дистанционного вызова, а также форматы посылаемых сообщений и сообщений получаемых в ответ.
• R-App постоянно, в режиме 24/7, представлены в Интернете и зарегистрированы в онлайн регистраторах (Online Registry).
• R-App приложения могутодновременно принимать участие в процессах (E-Process) разных типов и передавать данные из одного процесса в другой.
• R-App занимаются автоматическим мониторингом и управлением процессами (E-Process) В случае задержек, приложения могут в автоматическом режиме обращаться непосредственно к участникам с помощью смс или электронной почты.
• SAF-Model — это описание Ролей, Соглашений, Транзакций и API, выполненное на языке описания данных Proto 3.

Применение SAF может привести к следующим положительным сдвигам:

Автор: agoussia

Источник