Розробка ПЗ для експедиторів: Smart Freight від пропозиції до коносамента

Більшість посібників із розробки ПЗ для експедиторів починаються з переліку функцій: керування ставками, бронювання, відстеження, документи, рахунки. Ми починаємо із запису. У морських і контейнерних перевезеннях пропозиція, бронювання й коносамент описують те саме відправлення. Коли кожен із них живе в іншій поштовій скриньці чи системі, люди передруковують дані, і кожне передруковування — місце, де відправлення може зірватися.

Smart Freight — кейс, що стоїть за цією нотаткою: платформа бронювання морських вантажоперевезень для відправлень повним контейнером (FCL) на ринку Великої Британії. Logics7 будує її з 2024 року дотепер, і вона працює. Вантажовідправник порівнює пропозиції за маршрутами на карті, обирає тарифний рівень, бронює і спілкується з координатором відправлення в чаті. Чернетку коносамента формують із бронювання, щоб агент її перевірив.

Далі: де ламається бронювання вантажоперевезень, що робить платформа, як її побудовано і що це каже про вибір між розробкою і купівлею.

Бронювання контейнера досі відбувається через e-mail, телефонні дзвінки й таблиці. Ставка надходить у вкладенні. Правила free time і cut-off — у виносці. Підтвердження бронювання лежить в одній поштовій скриньці, а коносамент із нього передруковують в іншу систему.

Кожна передача між вантажовідправником, агентом і перевізником коштує дзвінка, затримки або помилки. Котирування — не запит на бронювання, запит на бронювання — не підтвердження, а підтвердження — не документ. Проте ті самі дані мають пройти через усі ці етапи: пара портів, перевізник, тип контейнера, розклад рейсів, відомості про вантаж.

Проблема не у відсутній функції. Проблема — у відсутності одного запису, спільного для пропозиції, бронювання й документів, і саме це розробка ПЗ для експедиторів має виправити насамперед. ПЗ для бронювання вантажоперевезень, яке додає екрани поверх того самого ланцюжка листів, переносить передруковування в інше місце, а не усуває його.

Smart Freight переносить шлях від котирування до бронювання і документи на одну платформу бронювання морських перевезень. Деталі продукту — у кейсі Smart Freight; тут — логіка.

Пропозиції за маршрутами й тарифні рівні

Пропозиції «порт — порт» з’являються на карті в реальному часі. Кожна показує перевізника, тип контейнера, cut-off, відправлення, прибуття, транзитний час і ціну, тож вантажовідправник порівнює факти, а не чекає на котирування поштою.

Кожна пропозиція має три тарифні рівні: Standard, Flexible і All inclusive. Рівні заздалегідь зазначають free time, гнучкість cut-off, демередж і рівень підтримки. Це керування фрахтовими ставками в момент вибору: ставки та їхні правила надходять разом, як частина пропозиції, а не дрібним шрифтом.

Бронювання і чат щодо відправлення

Процес бронювання проводить вантажовідправника через тарифний рівень, рейс, зведення бронювання з Incoterms і кроки підтвердження, показуючи загальну суму за контейнер. Нічого не списується, доки агент не підтвердить наявність місць.

Кожне бронювання має власний чат із координатором відправлення, поруч із системними сповіщеннями. Список відправлень показує статус кожного бронювання, а екран відстеження додає видимість відправлення. Розмова лишається прив’язаною до відправлення, якого вона стосується, а не до чиєїсь поштової скриньки.

Чернетка коносамента

Платформа формує чернетку коносамента з бронювання, з даними про перевезення і відомостями про вантаж; судно, рейс і порти є на кожному документі. Агент перевіряє чернетку, а не передруковує її.

Електронний коносамент (eBL) — окреме питання. DCSA публікує стандарт електронного коносамента; ця нотатка не робить заяв щодо eBL для Smart Freight. Платформа створює чернетку для агента.

Послідовність нижче — ядро продукту. Кожен крок належить до того самого запису відправлення; жоден не починається з порожньої форми.

Для тих, хто планує цифрове експедирування, це найважливіша частина розробки ПЗ для експедиторів. Найдорожчі помилки стаються між кроками, а не всередині них: неправильний тип контейнера в пропозиції стає неправильним бронюванням, а потім неправильним документом. Коли бронювання, розмова, сповіщення й чернетка коносамента стосуються одного відправлення, ніхто не передруковує те, що система вже знає.

Smart Freight — клієнтський продукт. Роль Logics7 охоплює структуру продукту, вебплатформу, процес бронювання й автоматизацію документів, з 2024 року дотепер. Технічні будівельні блоки — вебплатформа, карти й маршрутизація, чат у реальному часі та генерація документів.

Продукт сформували три рішення:

• →Пропозиції, а не листування щодо котирувань. Вантажовідправник порівнює факти на карті, а не чекає на лист.
• →Правила як частина продукту. Free time, cut-off і демередж належать до пропозиції, а не до дрібного шрифту, і нічого не списується, доки агент не підтвердить наявність місць.
• →Один запис. Бронювання, розмова, сповіщення й документи стосуються того самого відправлення.

Жодне з трьох не є технологічним вибором. Кожне визначає, як транзакція працює для вантажовідправника й агента, а код випливає з цього. На цьому принципі стоїть те, як працює Logics7: жодної розробки без продуктової логіки.

Це доводить, що транзакція, у якій ціна, правила й документи мають бути узгоджені, може працювати як один продукт, а не як ланцюжок листів, — без програми трансформації.

Для експедиторів і NVOCC перше питання в розробці ПЗ для експедиторів — розробити чи купити, і відповідь залежить від того, де саме ваша відмінність. Коробкові експедиторські пакети й ПЗ для NVOCC покривають типову бек-офісну роботу: документацію, митницю, рахунки, EDI/API-інтеграцію з перевізниками, зв’язок із TMS чи CRM. Якщо ваш процес збігається з пакетом, купуйте його. Власне логістичне ПЗ має сенс тоді, коли продуктом є сама клієнтська транзакція: як показано пропозиції, як сформульовано правила, як бронювання стає документом.

Та сама логіка підходить для маркетплейсів бронювання, клієнтських порталів статусу, відстеження відправлень, автоматизації рахунків і документів та операційних дашбордів. Для нового самостійного продукту це наш маршрут Product Partnership. Для наявної компанії, чиї операції тримаються на людях і таблицях, це Annual Product Operations: спершу бізнес-процес, потім річна дорожня карта, що виконується місяць за місяцем.