Розробка модуля маршрутизації для автопарку з 80 автомобілів обійдеться приблизно в 98 000 доларів у перший рік. Три роки використання корпоративного SaaS для того самого автопарку обійдуться у 256 700 доларів. Індивідуальна розробка за той самий період коштуватиме 152 080 доларів, і в кінці ви станете її власником.
Ці цифри можуть здатися привабливими і зробити індивідуальну розробку кращим варіантом. Але вони не дають відповіді на питання, чи буде вартість вашого власного проєкту близькою до них. Вартість розробки програмного забезпечення для оптимізації маршрутів залежить від того, скільки обмежень вам доведеться моделювати, чи працює диспетчерська служба за розкладом чи реагує на винятки в режимі реального часу, до скількох систем має підключатися система, та скільки ви платите за картографічні дані. Два автопарки однакового розміру можуть відрізнятися на 150 000 доларів за однакових технічних вимог.
Саме ціна за одиницю транспортного засобу змушує більшість підприємств досі розглядати кастомну розробку як кращий варіант. При вартості 40–60 доларів за транспортний засіб на місяць абонентська плата здається незначною порівняно з бюджетом на розробку, але одного дня ви виявите, що порівняння проводилося на основі неправильних цифр. Якщо ви все ще обираєте платформу, у нашому огляді найкращого ПЗ для диспетчеризації вантажних перевезень ви знайдете все, що наразі пропонує ринок.
Нижче ми розбираємо, скільки коштує індивідуальна розробка залежно від обсягу робіт, що впливає на зростання або зниження вартості, а також які витрати залишаються після запуску.
Коротко
- Вартість розробки програмного забезпечення для оптимізації маршрутів залежить від обсягу робіт. MVP для одного складу коштує 40 000–90 000 доларів, версія з декількома обмеженнями — 90 000–160 000 доларів, а платформа диспетчеризації в режимі реального часу — 160 000–250 000 доларів і більше.
- На суму впливають чотири фактори: кількість модельованих обмежень, перепланування маршрутів за розкладом чи в режимі реального часу, кількість систем, до яких підключається движок, та те, чи ви самостійно розміщуєте картографічні дані, чи купуєте ліцензію на них. Перепланування за розкладом чи в режимі реального часу є найважливішим окремим чинником.
- Бюджет навмисно зосереджується на початкових етапах — аудиті та пілотному впровадженні. Перевірка моделі обмежень на одному автопарку перед повним розгортанням у всьому автопарку — це те, що забезпечує передбачуваність розробки програмного забезпечення для оптимізації маршрутів.
- Найдешевший спосіб розробки — це розробляти менше: додатковий двигун, що підключається до вашої системи управління транспортом (TMS) та телематики через API, оцінюється за цінами, зазначеними у вищезазначених цінових рівнях, на відміну від повної заміни системи.
- Для автопарку з 80 транспортних засобів індивідуальне рішення коштує дорожче в перший рік, окупається на другий рік, а на третій рік дозволяє заощадити понад 104 000 доларів порівняно з SaaS, без обмеження вартості на один транспортний засіб та з повним правом власності на інтелектуальну власність.
Скільки коштує розробка програмного забезпечення для оптимізації маршрутів?
Ми не можемо назвати єдину ціну, але існує надійний діапазон, коли ви знаєте, що саме розробляєте. Вартість розробки залежить більше від обсягу робіт, ніж від розміру автопарку, оскільки розробка для компанії з 200 транспортними засобами, що працює за запланованими маршрутами з одним депо, може коштувати дешевше, ніж для автопарку з 40 транспортними засобами, який потребує перепланування маршрутів у режимі реального часу та додатка для водіїв.
Більшість проектів з оптимізації маршрутів належать до одного з трьох рівнів.
| Обсяг | Типовий діапазон | Що охоплює |
|---|---|---|
| MVP маршрутизації | 40 000–90 000 доларів | Один склад, планове відправлення, налагоджений відкритий програмний вирішувач (OR-Tools, VROOM) та одна інтеграція у вашу систему управління перевезеннями (TMS). Вирішує проблему «ціноутворення за кожним транспортним засобом вже не відповідає нашим потребам» без значних додаткових зусиль. |
| Конфігурація з декількома обмеженнями | 90 000–160 000 | Кілька складів, правила щодо робочого часу водіїв та дотримання вимог, зіставлення характеристик транспортних засобів та телематичний канал у режимі реального часу. Рішення, яке обирає більшість автопарків, що розширюються. |
| Платформа диспетчеризації в режимі реального часу | 160 000–250 000+ доларів | Усе вищезазначене, а також перепланування маршрутів у режимі реального часу з урахуванням дорожнього руху та скасувань, додаток для водіїв, консоль диспетчера та динамічне ціноутворення або логіка розрахунку очікуваного часу прибуття (ETA). |
Діапазони відображають поточні ринкові орієнтири для індивідуальних рішень з оптимізації маршрутів (середина 2026 року), а не фіксовані ціни від Stfalcon. Фактична вартість залежить від ваших обмежень та обсягу інтеграції — отримайте кошторис з урахуванням конкретних параметрів.
Приклад із 80 транспортними засобами, який розглядається в подальшій частині цієї статті (вартість розробки якого в перший рік становить близько 98 000 доларів), належить до другого рівня: кілька обмежень, телематичний канал даних, одна основна інтеграція. Перехід між рівнями визначається не стільки кількістю рядків коду, скільки тим, на що двигун має реагувати в режимі реального часу, та кількістю зовнішніх систем, з якими він має синхронізуватися.
Одне рішення розділяє рівні більше, ніж будь-яке інше: заплановане диспетчерське управління проти обробки винятків у режимі реального часу. Ми повернемося до цього в розділі про фактори, що впливають на вартість, оскільки це змінює як вартість розробки, так і щомісячний рахунок.
Що впливає на вартість розробки програмного забезпечення для оптимізації маршрутів
Дві збірки для автопарку однакового розміру можуть опинитися на різних рівнях. Їх відрізняє короткий перелік рішень, і вони мають різну вагу. Ось вони, приблизно в порядку того, наскільки сильно вони впливають на цифру.
Кількість обмежень — це перша розгалуження. Розв’язувач, який лише упорядковує зупинки за відстанню, — це зовсім інше завдання, ніж той, що одночасно враховує обмеження щодо робочого часу водія, вагу та габарити транспортного засобу, часові вікна доставки та зони дотримання транскордонних вимог. Кожне обмеження — це логіка, яку хтось має змоделювати, перевірити на реальних маршрутах та підтримувати.
Комерційне планування маршрутів для вантажівок має враховувати розмір і вагу вантажівки, правила доступу до міських територій, витрати на проїзд та законодавчі вимоги щодо періодів відпочинку; саме тому розробка для перевезення важких вантажів коштує дорожче, ніж для кур’єрських фургонів, і причина цього не полягає в обсязі коду.
Плановий режим проти режиму реального часу — це друга проблема, і вона має подвійний вплив. Вона змінює структуру системи та щомісячний рахунок протягом усього терміну роботи системи.
| Підхід | Як це працює | Вплив на розробку | Витрати на виконання |
|---|---|---|---|
| Евристичні алгоритми VRP | Пошук наборів маршрутів, близьких до оптимальних, що обчислюються одноразово або за розкладом. | Нижчі. Оптимізатори з відкритим кодом (OR-Tools, VROOM, OptaPlanner), налаштовані відповідно до ваших правил. | Низькі — пакетне обчислення, мінімальна кількість запитів до API в режимі реального часу. |
| Динамічне перепланування маршрутів з використанням штучного інтелекту | Постійно перераховує маршрути з урахуванням поточного дорожнього руху, нових замовлень, скасувань та затримок водіїв. | Вищий рівень. Потрібні канал передачі даних у реальному часі, інтеграція з телематичними системами та постійна оцінка маршрутів. | Вищий рівень — потокові дані GPS та облік використання API карт за кожним запитом, що масштабується відповідно до обсягу. |
Більшість виробничих систем використовують обидва підходи: евристичний алгоритм для ранкового плану диспетчеризації та логістичний ШІ, який обробляє винятки, що виникають на дорозі. Визначення того, що саме потрібно вашому бізнесу, є найважливішим фактором, що впливає на вартість — легко переоцінити необхідність роботи в режимі реального часу, коли запланована диспетчеризація цілком впорається з навантаженням.
Третім фактором є поверхня інтеграції. Механізм маршрутизації цінний лише настільки, наскільки він інтегрований з іншими системами. Кожна система, з якою він має обмінюватися даними, включаючи вашу TMS, ERP, GPS та телематичні потоки, а також додаток для водіїв, — це інтерфейс, який потрібно побудувати та підтримувати в синхронізації. Одна чітка інтеграція з TMS — це окрема позиція в кошторисі, тоді як п’ять двосторонніх синхронізацій — це цілий проєкт.
Якщо спочатку потрібно доопрацювати ваш основний диспетчерський стек, це швидко розширює обсяг робіт. У нашому посібнику про те, як побудувати кастомну TMS, розповідається, де пролягає ця межа.
Картографічні дані — це четвертий пункт, і саме на нього команди часто забувають передбачити кошти в бюджеті. Самостійне хостингування двигуна з відкритим кодом (OSRM, Valhalla) дозволяє утримати періодичні витрати майже на рівні нуля, але покладає на вас відповідальність за обслуговування карт. Комерційні провайдери, такі як HERE або PTV, виставляють рахунки за кожну транзакцію — перші кілька тисяч запитів безкоштовні, а потім вартість становить кілька доларів за тисячу, і зростає з кожним обчисленим маршрутом. Для диспетчерської служби з великим навантаженням це щомісячний постійний витратний пункт, а не одноразові витрати, тому це питання слід враховувати під час розробки, а не лише у бюджеті на запуск.
Розмір автопарку навмисно майже не згадується в цьому списку. Він безпосередньо впливає на вартість SaaS, але в разі індивідуальної розробки в основному впливає на обчислювальні потужності та ліцензування на периферії — архітектура коштує однаково, незалежно від того, чи прокладається маршрут для 40, чи для 140 транспортних засобів.
Посібник із розробки ПЗ для оптимізації маршрутів: куди йдуть кошти
Знати загальну суму — це не те саме, що знати, коли ви її витратите. У Stfalcon, наприклад, проект розробки індивідуального програмного забезпечення для оптимізації маршрутів проходить у чотири етапи, і вони коштують по-різному. Вкладення коштів на початковому етапі в аудит та пілотний проект перед повним розгортанням у всьому автопарку дозволяє нам забезпечити передбачуваність проекту та уникнути ситуації, коли наші клієнти платять за переробку неправильно розробленого продукту.
| Етап | Що відбувається | Частка бюджету | Які ризики усуваються |
|---|---|---|---|
| Аудит | Визначте всі обмеження маршрутизації, з якими ваш поточний інструмент справляється погано або взагалі не справляється: часові вікна, правила для водіїв, логіка роботи депо, зони відповідності вимогам. | ~10–15% | Запобігає створенню системи, яка повторює «сліпі зони» старого інструменту. |
| Пілот | Створіть двигун і запустіть його для одного складу або кластера маршрутів паралельно з існуючою платформою. | ~35–45% | Перевірте модель обмежень на реальних даних, перш ніж весь автопарк почне покладатися на неї. |
| Розширення | Впровадити систему в решті автопарку; підключити її до TMS, GPS та диспетчерської служби. | ~30–35% | Масштабуйте те, що вже перевірено, замість того, щоб масштабувати припущення. |
| Стабілізація | Налаштуйте систему під навантаження, відстежуйте крайні випадки, виведіть зі служби старий інструмент. З цього моменту починається постійний моніторинг SLA та оновлення наборів даних карт. | ~10–15% | Закріплює економію та назавжди скасовує плату за кожен транспортний засіб. |
Пілотний проект — це етап, на якому метод окупається, і саме його більшість команд прагне пропустити. Пропустити його здається швидшим, оскільки так можна швидше перевести весь автопарк на новий двигун. Але насправді це означає, що ви ставите під загрозу всю свою систему маршрутизації, покладаючись на модель обмежень, яку ще ніхто не перевіряв на реальних даних. Реальні маршрути одного депо виявлять крайні випадки невідповідності або особливості логіки депо, які пропустив ваш аудит, поки їх ще дешево виправити.
Такий поділ на етапи також пояснює, чому попередні рівні мають саме такі діапазони. MVP з одним депо — це здебільшого аудит і пілотний проект із невеликим розширенням, і ви, можливо, ніколи не вийдете за межі першого етапу третьої фази. Платформа реального часу вимагає значних витрат на розширення і фактично ніколи не виходить за межі стабілізації, оскільки перепланування маршрутів у реальному часі потребує постійного налаштування з урахуванням даних про трафік і телематику, які постійно змінюються.
Витрати, що продовжуються після запуску
Сума витрат на розробку — це та цифра, яку наводять, щодо якої сперечаються та яку заносять до бюджету. Про поточні витрати часто забувають, а саме вони є більш справедливим критерієм порівняння з підпискою на SaaS, оскільки це сума, яку ви продовжуєте сплачувати щороку, доки система працює.
Поточні витрати складаються з чотирьох складових.
Технічне обслуговування. Плануйте 15–25 % від початкової вартості розробки на рік. Для системи вартістю 98 000 доларів це становить приблизно 15 000–24 000 доларів щорічно, що покриває виправлення помилок, налаштування алгоритму розв’язання задач та підтримку системи в актуальному стані у міру зміни ваших маршрутів і правил. Ця цифра стосується лише планових робіт — вартість екстрених виправлень у кілька разів перевищує вартість звичайних, що є аргументом на користь системи з технічним обслуговуванням, а не відкладеної.
Хостинг та інфраструктура. Витрати є помірними та передбачуваними, якщо ви самостійно хостите алгоритм з відкритим кодом; вони становлять кілька тисяч доларів на рік на обчислювальні потужності, які плавно масштабуються відповідно до обсягу даних.
Картографічні дані. Витрати, що змінюються залежно від використання. Комерційний постачальник виставляє рахунки за кожну транзакцію, тому операція перепланування маршрутів у реальному часі, що виконується цілий день, обходиться значно дорожче, ніж автопарк, який щоранку здійснює одне заплановане відправлення. Самостійне розміщення змінює це на майже нульові періодичні витрати в обмін на внутрішнє обслуговування карти — той самий відгалуження від факторів, що впливають на вартість, яке тепер відображається як щомісячна сума.
Підтримка за угодою SLA. Підтримка в робочий час майже не змінює базову вартість обслуговування. Гарантія безперебійної роботи 24/7, яка необхідна для оперативної диспетчерської служби, додає до неї 20–40 %. Варто ретельно прорахувати вартість: якщо водії перебувають у дорозі о 2-й годині ночі, SLA не є опцією.
Підсумуємо: індивідуальна розробка середнього рівня має періодичні витрати, що значно нижчі за ті, які той самий автопарк сплачує за SaaS за кожну одиницю транспорту; іншими словами, саме ця різниця, розрахована на три роки, перетворюється на реальні гроші.
Хочете розрахувати вартість власної системи?
Повідомте нам розмір вашого автопарку і ваші обмеження, і ми проаналізуємо цифри, спираючись на 16 років досвіду у створенні логістичних рішень.
Аліна
Менеджерка з роботи з клієнтами
Як створити ПЗ для оптимізації маршрутів без зайвих витрат
Найефективніший з точки зору витрат спосіб розробки програмного забезпечення для оптимізації маршрутів — це створення додаткового модуля, спеціалізованого двигуна, який підключається до вашого існуючого стеку через легкі API та не зачіпає решту системи.
Цей єдиний архітектурний вибір має більшу цінність для бюджету, ніж будь-яке рішення щодо алгоритму. Повна перебудова платформи коштує як багаторічний корпоративний проєкт, тоді як додатковий механізм маршрутизації коштує так само, як рівні, описані раніше в цій статті, оскільки він має лише добре виконувати одну функцію та чітко взаємодіяти з системами, які вже виконують решту завдань.
Більшу частину цієї роботи виконують три точки інтеграції:
TMS та ERP. Механізм отримує необроблені замовлення та вікна доставки, упорядковує їх і передає оптимізовані маршрути назад у диспетчерську службу без необхідності втручатися в основну систему обліку. Якщо спочатку потрібно доопрацювати ваш основний стек, це окреме рішення, і наш посібник « Як побудувати кастомну TMS» пояснює, де пролягає ця межа.
Телематика та GPS. Двигун підключається до обладнання, яке ви вже використовуєте — будь то Samsara, Geotab чи мобільний додаток для водіїв — щоб зчитувати фактичні координати транспортних засобів, а не заплановані. Повторне використання наявного потоку даних є кращим варіантом, ніж включення нового обладнання в проект.
Сумісність із SaaS. Під час міграції двигун працює паралельно з вашою поточною платформою, беручи на себе складні маршрути з обмеженнями, тоді як старий інструмент обробляє стандартні замовлення. Ви ніколи не опинитеся в ситуації, коли під час переходу нічого не працює, що дозволяє зберегти низький рівень ризику та низькі витрати на етапі «Пілот».
Якщо розглядати двигун як інтеграційний шар, а не як замінник, розробка вкладається в передбачуваний чотиримісячний термін і не переростає у повне переписання коду, яке вам ніколи не було потрібно. Загальне правило таке: кожна система, до якої ви підключаєтеся, обходиться дешевше, ніж кожна система, яку ви перебудовуєте.
Розрахунок за 3 роки: що насправді економить розробка
Передплата — це єдина вартість, яка відображається у рахунку-фактурі, тоді як решта прихована в експлуатаційних витратах. Диспетчери, які вручну переплановують зупинки, другий депо, що відстежується в окремій таблиці, квиток на підтримку для кожного правила, від якого платформа не відступає, — це те, що ми називаємо «множником витрат SaaS», операційним податком, який зростає у міру розширення автопарку.
Саме тому порівняння вартості передплати з кошторисом на розробку призводить до неправильного рішення, оскільки ви порівнюєте видимі витрати з загальними.
На основі аудитів Stfalcon середніх автопарків, ось трирічний графік для підприємства з 80 автомобілями, що зростає на 10% щороку, у порівнянні зі стандартними показниками маршрутизації для підприємств.
| 1-й рік | 2-й рік | 3-й рік | ||||
|---|---|---|---|---|---|---|
| Категорія витрат | SaaS | На замовлення | SaaS | Індивідуальне | SaaS | На замовлення |
| Програмне забезпечення / Хостинг | 52 800 | 6 000 | 58 080 | 6 300 | 64 020 | 6 600 |
| Початкова розробка / налаштування | 0 | 98 000 | 0 | 0 | 0 | 0 |
| Технічне обслуговування / Оновлення | 0 | 3 000 | 0 | 12 000 | 0 | 12 000 |
| Ручне обхідне рішення | 22 000 | 2 200 | 26 000 | 2 600 | 33 800 | 3 380 |
| Річний підсумок | 74 800 | 109 200 | 84 080 | 20 900 | 97 820 | 21 980 |
| Сукупна вартість володіння | 74 800 | 109 200 | 158 880 | 130 100 | 256 700 | 152 080 |
Лише ілюстративна модель. На основі операційних аудитів Stfalcon середніх автопарків (50–500 автомобілів) та порівняльних показників цін на корпоративні SaaS-рішення.
- Ціни на SaaS розраховано за стандартними корпоративними рівнями маршрутизації (в середньому 55 доларів за транспортний засіб на місяць).
- Зростання автопарку з 80 до 97 автомобілів протягом трьох років безпосередньо спричиняє лінійне зростання вартості передплати на SaaS.
- Розрахунок впливу на фонд оплати праці базується на середній зарплаті диспетчера у розмірі 50 тис. доларів на рік, причому 20 % оплачуваного робочого часу витрачається на ручне втручання. У 2-му та 3-му роках ці операційні витрати зростають приблизно на 30 % через збільшення автопарку та ускладнення маршрутів. У разі індивідуальних розробок кількість обхідних рішень зменшується на 90 %, а не зникає повністю, що пояснюється неминучими крайніми випадками в реальних умовах.
- Сума в 98 000 доларів у 1-му році — це початкова капітальна інвестиція (CapEx) у цільовий маршрутизатор MVP. Плата за хмарну інфраструктуру незначно зростає разом з обсягом даних. Ці цифри базуються на припущенні, що використовуються самостійно розміщені маршрутизатори (наприклад, OSRM, Valhalla), а використання комерційних картографічних API оплачується окремо, якщо це необхідно.
- Витрати на технічне обслуговування у 1-му році охоплюють підтримку згідно з угодою про рівень обслуговування (SLA) після запуску, що настає після завершення початкового етапу розробки та гарантійного терміну.
Як бачите, у 1-му році перевага на боці SaaS, і це не дивно. Індивідуальна розробка спочатку коштує дорожче, як і слід було очікувати, але до кінця 2-го року індивідуальна платформа вже виявляється на 28 780 доларів дешевшою в сукупності. До кінця 3-го року різниця збільшується до 104 620 доларів, і, на відміну від підписки, з іншого боку цієї межі немає обмеження вартості на один транспортний засіб. Рішення про розробку програмного забезпечення для оптимізації маршрутів перестає бути актом віри, щойно точка перетину з’являється на графіку.
Важливішою за точні цифри є динаміка. Крива SaaS виглядає рівною, але піднімається з кожним доданим автомобілем; індивідуальна розробка вимагає початкових витрат, а потім вирівнюється. Чим стрімкіше ваше зростання, тим швидше лінії перетинаються.
Коли індивідуальне рішення перевершує SaaS: приклад з реального життя
BBGO — це сервіс замовлення поїздок, який працює на ринку понад 16 років. Замовлення поїздок — це не перевезення важких вантажів, але BBGO зіткнувся з тією самою перешкодою, з якою стикається кожна компанія, що масштабується: її стороння SaaS-платформа більше не могла підтримувати зростання. Жорстка логіка підбору водіїв не залишала місця для функцій, необхідних BBGO, а витрати на хостинг зростали разом із обсягом роботи (мультиплікатор витрат на SaaS проявився у реальних цифрах).
Спільно зі Stfalcon компанія BBGO замінила платформу на індивідуальну систему, побудовану на основі власної логіки диспетчеризації. Саме вибір інфраструктури зробив економічну модель конкретною: Stfalcon з самого початку створила для BBGO хмаронезалежну систему на базі Kubernetes, тому коли клієнт під час пандемії захотів скоротити витрати на хмарні послуги, перехід з Google Cloud на дешевший Hetzner відбувся швидко й без перебоїв у роботі. Така переносимість є важелем контролю витрат, якого просто не дає передплата на SaaS.
BBGO вийшла з цієї ситуації з нижчими операційними витратами, повним контролем над своїм планом розвитку та відсутністю обмежень на зростання за кількістю користувачів, і зараз обробляє понад 50 000 замовлень на місяць.
Готові порівняти вартість вашого рішення з витратами на SaaS протягом ще трьох років?
Давайте визначимо реальну цифру для вашого парку.
Аліна
Менеджерка з роботи з клієнтами
Найдорожчою частиною є не код
Найдорожчим етапом розробки кастомного ПЗ є процес навчання, а не сам код. Це ціна того, що все доводиться з’ясовувати на ходу: команди інженерів-універсалів створюють програмне забезпечення для маршрутизації методом проб і помилок, стягуючи з вас плату за кожен нестандартний випадок у логістиці, який їм не вдалося передбачити.
За понад 16 років компанія Stfalcon реалізувала понад 387 логістичних проєктів із рівнем успішності 99%. Наша компанія з розробки ПЗ для транспортної галузі використовує перевірені на практиці компоненти та галузеву експертизу, щоб впровадити ваш індивідуальний двигун передбачувано, у межах бюджету та без простоїв.
