Протягом багатьох років «відкритий вихідний код» використовувався навколо технології експедирування вантажів як абстрактного ідеалу, а не практичної робочої моделі. Усім відомо, що це лежить в основі Інтернету, хмарної інфраструктури та розробки сучасного програмного забезпечення. Але мало хто сперечався, що він може розташовуватися десь поблизу операційного серця експедитора.
Можливо, зараз це починає змінюватися. Не тому, що відкритий вихідний код раптово став більш спроможним, а тому, що після запуску нових цінних пакетів CargoWise та розчарування промисловості через її контроль над сектором TMS, системи ставляться під сумнів більш відкрито.
Експедитори більше не просто запитують, що може зробити їх TMS; вони запитують, хто врешті-решт контролює робочі процеси, дані та швидкість, з якою вони можуть адаптуватися.
Зараз зростає кількість прихильників, які стверджують, що майбутнє технології пересилання — це не ще одна пропрієтарна платформа, а спільна відкрита інфраструктура.
FreightTech.org є одним із найчіткіших артикуляцій цієї ідеї. Але засновник і генеральний директор Себастьян Врубель обережно, щоб не представити те, що він створює, як пряму заміну CargoWise або інші наскрізні системи. Натомість він побудований на ліцензованих MIT модулях Open Mercato, які охоплюють такі сфери, як бронювання, планування, закупівлі та обробка документів, призначені для збирання, адаптації та розширення експедиторами чи постачальниками, як вони вважають за потрібне.
У цій структурі TMS стає не монолітом, а більшою схемою: набором компонентів, інтеграцій і послуг, якими можна володіти, замінювати або змінювати, не запитуючи дозволу в одного постачальника.
Важливо те, що FreightTech не заперечує, що більшість експедиторів все ще хочуть мати постачальника на іншому кінці телефону. Його власна комерційна роль полягає в приватному рівні інтеграції даних, а також додаткові послуги хостингу та впровадження, інструменти, за їх словами, уже можуть бути замінені альтернативами, якщо захочуть клієнти, і які, як стверджується, будуть відкритими у випадку банкрутства компанії.
Швидкість і вартість — дві переваги, сказав пан Wróbelзазначивши, що модуль був побудований за п’ять тижнів.
«Наш підхід… з самого початку [was] не просити нікого фактично платити за доступ до даних… це має бути безкоштовно, e тому що це сприятиме продуктивності».
Але ідея про те, що відкритий вихідний код може значною мірою підтримувати операції з пересилання, залишається спірною навіть серед тих, хто в цілому симпатизує напрямку руху.
Брайан Ґлік, засновник Chain.io і колишній експедитор, зрозуміло, що відкритий код сам по собі не є проблемою.
«Усе, що всі використовують, — це програмне забезпечення з відкритим кодом», — зазначив він. Однак там, де це було успішно, це на рівні компонентів, а не як готові робочі продукти.
«Це було успішно на рівні кубиків Lego, а не Lego», — каже він. Механізми маршрутизації, бібліотеки та стандарти добре працюють як будівельні блоки, але експедитори, стверджував він, все ще хочуть системи, які працюють із коробки, з постачальником, службою підтримки та чіткою підзвітністю.
Це повторює Роберт Петті, генеральний директор Prompt Global, який поставив під сумнів використання відкритого коду як основної операційної моделі. Експедитори, за його словами, не є компаніями, що займаються програмним забезпеченням, а проекти з відкритим кодом без чіткого економічного двигуна мають довгу історію стагнації.
Ці занепокоєння сильно резонують з операторами, але вони не закрили двері для цього.
Джеймі Андраде, старший віце-президент з управління продуктами Seko Logistics, описала рух відкритого коду в експедиції як те, за чим вона уважно стежить.
«Сьогодні ми не використовуємо це в будь-якому масштабі», — каже вона. “Я спілкувався з кількома початківцями, які намагалися потрапити на ринок TMS із таким мисленням відкритого вихідного коду. Я не збираюся відразу кидатися на підножку, але я можу стати в чергу за квитком. Я хочу побачити, що станеться”.
Те, що цікавить пані Андраде, — це не ідея виривання існуючих систем, а можливість прискорення інтеграції в галузі, яка визначається фрагментацією. Переміщення вантажу з пункту А в пункт Б може залучати десятки сторін, кожна зі своїми системами та інтерфейсами.
«Створення свого роду відкритого вихідного коду, майже як магазин додатків, де ви можете розмістити рішення для митниці в цій країні або обміну повідомленнями в цій країні, і кожен зможе ним користуватися – це цікаво», – сказала вона. «Ви отримуєте користь від розміщення свого рішення».
Теоретично ця модель могла б дозволити експедиторам монетизувати нішеві можливості, а не ховати їх у створених на замовлення внутрішніх системах. Наприклад, індивідуальну митну інтеграцію можна використовувати в ширшій мережі, приносячи дохід і одночасно зменшуючи дублювання зусиль.
У той же час пані Андраде чітко розуміє конкурентні та культурні проблеми. Вона запитала: “Чи хочу я платити своєму конкуренту? Ні. Але це цікавий підхід”.
Ця амбівалентність фіксує ширший настрій. Відкритий вихідний код не сприймається як «срібна куля» і не відкидається як нереалістичний. Натомість його розглядають як спосіб послабити хватку монолітних платформ, не відмовляючись від постачальників взагалі.
Дискусія щодо цін не зробила відкритий вихідний код життєздатним. Але те, що він зробив, це змусив експедиторів зіткнутися з ціною залежності та розглянути архітектури, які дозволяють часткові виходи, а не міграції «все або нічого».
Нічого з цього не означає, що масовий відхід із існуючих платформ TMS неминучий.
Як зазначив пан Ґлік, більшість експедиторів продовжуватимуть віддавати пріоритет простоті, підтримці та підзвітності. Для багатьох зручність одного постачальника все одно переважить привабливість більшої автономії.
Але поява надійної інфраструктури з відкритим вихідним кодом свідчить про зміну поглядів на технологію пересилання. Питання більше не в тому, чи може відкритий код замінити TMS, а в тому, чи може TMS залишатися беззаперечним центром тяжіння.
Слідкуйте за сьогоднішнім подкастом «Коротко про новини»!
