Як AgriChain оцифрувала техніку, логістику та польові роботи і створила власну систему управління для агропромхолдингу «Астарта-Київ»
AgriChain — внутрішня продуктова ІТ-компанія агропромхолдингу «Астарта-Київ», створена у 2017 році, яку очолює Наталія Богачева.
Останні кілька років AgriChain була зосереджена на внутрішній цифровій трансформації бізнесу. Одним із ключових проєктів стала розробка AgriChain Machinery — власної системи GPS-моніторингу та операційного управління технікою, яку компанія створювала протягом чотирьох років.
«Астарта» обробляє близько 212 тис. гектарів земельного банку, належить до найбільших виробників цукру в Україні та є одним із лідерів молочного напряму. Відповідно, система мала охопити не лише польові роботи, а й логістику, переробку, елеваторний напрям та інші суміжні процеси.
— Пані Наталіє, як сьогодні працює AgriChain і на яких напрямах компанія зосереджена?
— AgriChain фактично виконує роль технологічного бізнес-партнера холдингу та відповідає за розвиток усієї цифрової екосистеми «Астарта-Київ». Сьогодні вона налічує понад 12 модулів — це вебплатформи, мобільні застосунки та спеціалізовані цифрові сервіси для рослинництва, тваринництва, цукрового виробництва, елеваторного напряму й корпоративного управління.
Навіть в умовах повномасштабної війни ми не зупинили розвиток цифрових продуктів. Команда запустила рішення для навчання персоналу, CRM-системи, інструменти оцінки контрагентів, security-рішення, а також активно працює з AI-напрямом. Зокрема, зараз ми тестуємо внутрішній продукт Astarta AI, який поєднує технології LLM та Computer Vision для підтримки роботи різних категорій спеціалістів.
— Чому AgriChain та «Астарта» вирішили створити власну систему GPS-моніторингу і які завдання вона мала розв’язати?
— Модуль управління технікою — AgriChain Machinery — залишався одним із найбільш комплексних викликів для компанії. Ми побачили, що більшість класичних систем GPS-моніторингу обмежуються передачею телеметричних даних із GPS-трекерів, датчиків рівня пального та іншого обладнання. Однак самі по собі ці дані не створюють управлінської цінності без інтеграції в операційні процеси.
Для нас було важливо поєднати телеметричні дані з операційною діяльністю. Йшлося про побудову наскрізного процесу — від планування робіт і замовлення техніки до контролю виконання технологічних операцій, оцінки якості робіт, логістики врожаю й транспортування готової продукції. Фактично ми ставили перед собою завдання створити єдину цифрову систему управління операційною діяльністю.
— Чому ви не обрали готове ринкове рішення?
— Ми аналізували різні продукти, представлені на ринку, зокрема певний час використовували зовнішню систему GPS-моніторингу Dozor, яка на початковому етапі закривала базові потреби компанії. Проте зі зростанням масштабів цифровізації ми почали стикатися з її функціональними обмеженнями.
Крім того, ми не знайшли на ринку комплексного продукту, який міг би безшовно інтегрувати всю кількість виробничих, логістичних та управлінських процесів, необхідних для нашої моделі бізнесу.
Окремим викликом була зручність користування платформою. Ми свідомо інвестували в сучасну технологічну архітектуру, UI/UX та логіку інтерфейсів, адже навіть найскладніша система має залишатися зрозумілим інструментом для користувачів, які щодня працюють із технікою, логістикою та операційними процесами. AgriChain Machinery побудована на сучасній архітектурі, що дає змогу масштабувати платформу та інтегрувати нові сервіси без зупинки операційних процесів.
— Які саме процеси вдалося об’єднати в системі та чим вона відрізняється від традиційних GPS-рішень?
— Фактично ми інтегрували кілька рівнів управління, які раніше існували ізольовано один від одного.
Перший — інфраструктурний рівень, тобто робота безпосередньо з обладнанням. Для нас було принципово працювати не з уже обробленими даними сторонніх сервісів, а із сирими даними безпосередньо з обладнання. Йдеться про GPS-трекери, датчики рівня пального, RFID- та BLE-мітки й інші телеметричні пристрої. Ми самостійно отримуємо ці дані, аналізуємо їхню структуру та використовуємо у конкретних бізнес-процесах. Такий підхід забезпечив більшу гнучкість і можливість швидко адаптувати систему під нові операційні сценарії.
Другий рівень — операційний контроль, який став ключовим елементом платформи. Наприклад, якщо техніка виконує обприскування, система визначає:
- чи справді техніка працювала на конкретному полі;
- чи виконувала саме заплановану операцію;
- чи дотримані параметри якості;
- чи були пропуски або перекриття;
- чи відповідав нормі швидкісний режим;
- чи виникали простої під час виконання робіт.
Усі ці параметри контролюються в межах конкретного поля як геозони, де система ідентифікує заплановану операцію та автоматично відстежує відхилення від заданих параметрів.
У разі фіксації відхилень платформа автоматично формує інциденти (сповіщення), які далі опрацьовують диспетчери або відповідальні менеджери. Ми розробили внутрішній конструктор інцидентів, який дає змогу налаштовувати бізнес-логіку контролю під конкретні завдання та операційні сценарії. Наприклад, система може окремо відстежувати роботу техніки поза визначеними геозонами, виконання операцій без підтвердженого наряду, порушення швидкісного режиму, простої в межах поля або повторний обробіток ділянок.
Отже, важливим блоком стала система управління інцидентами та контролю відхилень. Причому її використовують не лише класичні диспетчерські або моніторингові служби. У нашому випадку одним із ключових користувачів платформи стала також служба безпеки. Якщо система фіксує критичне порушення або потенційно ризикову подію, інформація автоматично передається через чат-боти групам оперативного реагування. Далі відповідальні команди безпосередньо на місці перевіряють ситуацію, аналізують причини інциденту та оцінюють можливі матеріальні або операційні ризики для бізнесу.
Окремий функціональний блок — контроль використання пального. Платформа відстежує заправки, зливи та загальний рух пального, а також інтегрована з внутрішньою системою автоматизованих заправних станцій. Це дає змогу контролювати весь ланцюг використання пального та оперативно реагувати на будь-які аномалії.
— Наскільки глибоко система інтегрована в логістичні процеси?
— Операційна логістика, зокрема вивезення врожаю, — один із найбільших функціональних блоків системи. Ми хотіли контролювати не окремі етапи процесу, а весь логістичний ланцюг: від моменту завантаження в полі до фінальної точки розвантаження на елеваторі або бурякоприймальному пункті.
Система інтегрована з механізмом «свій — чужий», тож можна ідентифікувати транспорт під час завантаження. Ми бачимо момент фактичного відвантаження, розуміємо, які транспортні засоби перебувають у відповідному радіусі, а із зовнішніх систем отримуємо товарно-транспортну накладну, яка автоматично прив’язується до конкретного рейсу.
Далі система відстежує весь маршрут транспортного засобу: від поля до точки розвантаження із фіксацією всіх тривожних подій.
Фактично контролюється кожен цикл рейсу:
- де відбулося завантаження;
- скільки було виконано відвантажень;
- чи була оформлена товарно-транспортна накладна;
- чи доїхав транспорт до точки призначення;
- чи були зупинки в дорозі;
- чи відхилявся транспорт від затвердженого маршруту.
Окремим складним напрямом стала цифровізація маршрутів. Протягом останніх трьох років ми оцифровували всю логістичну інфраструктуру: основні маршрути, альтернативні шляхи, точки завантаження і розвантаження.
Сьогодні система автоматично контролює рух транспорту відповідно до цих маршрутів і сигналізує про будь-які відхилення.
Щоб користувачі могли працювати із цією інформацією максимально гнучко, ми також розробили конструктор звітів, управлінські дашборди та аналітичні модулі. Це дає змогу формувати звітність під конкретні управлінські завдання й отримувати оперативну аналітику для ухвалення рішень.
— Як система розв’язує питання обліку виконаних робіт і контролю їхньої якості?
— Автоматичний розрахунок фактично виконаного обсягу польових робіт став одним із найскладніших завдань проєкту. Майже три роки ми розробляли і тестували алгоритм розрахунку відпрацьованих гектарів. Це складна математична модель, яка працює з GPS-треком техніки та відсікає некоректні дані, зокрема розвороти, діагональні проходи, технічні переміщення й інші елементи, які можуть спотворювати фактичний обсяг виконаних робіт. Ми не стверджуємо, що алгоритм є ідеальним — до таких моделей завжди виникатимуть питання, але сьогодні нам вдалося досягти точності з відхиленням у межах близько 5%, і для операційного управління це вже якісний результат.
Ми розраховуємо, що вже в поточному сезоні зможемо повністю закривати частину польових операцій на основі автоматично розрахованих гектарів без додаткових ручних підтверджень. Проте важливо не лише порахувати площу виконаних робіт. Платформа також оцінює якість виконання польових операцій, і саме тут вона безпосередньо інтегрована в систему мотивації механізаторів.
Платформа формує агрегований показник якості виконання робіт, який враховує пропуски під час виконання операцій, перекриття, дотримання швидкісних режимів, простої з увімкненим двигуном та інші параметри, від яких залежить ефективність роботи техніки. Усі ці показники безпосередньо впливають на винагороду конкретного механізатора. Тепер кожен учасник процесу розуміє: якість виконання роботи напряму впливає на його фінансовий результат.
Окрім польових операцій, система також охоплює широкий спектр логістичних і транспортних процесів: управління складською логістикою, внутрішні переміщення транспорту, облік пробігів, контроль простоїв, місцерозташування техніки в геозонах, облік мотогодин та інші параметри.
Усі ці дані використовують не лише для оперативного контролю, а й для формування первинної документації і закриття виробничих процесів. Для великого агробізнесу це критично, адже ручний облік виконаних робіт завжди створює ризики неточностей або маніпуляцій. Ми прагнули максимально автоматизувати цей процес.
— Які нові функції ви зараз додаєте в систему і хто працює з нею всередині компанії?
— Якщо говорити про подальший розвиток платформи, то одним із наших пріоритетів є посилення блоку управління технічним парком. Окрім контролю руху техніки, ефективності її використання, польових, транспортних і логістичних операцій, ми розвиваємо окремий модуль управління ремонтами й технічним обслуговуванням, тобто формуємо повноцінну цифрову сервісну історію кожної одиниці техніки.
Платформу від початку проєктували як універсальне цифрове рішення для всіх бізнес-напрямів «Астарти». Сьогодні вона вже охоплює рослинництво, транспортну логістику, цукровий напрям і поступово масштабується на тваринництво та суміжні операційні процеси.
— Багато фермерів скаржаться на проблеми із сигналом саме в тих областях, де працює «Астарта». Як ви розв’язали це питання?
— Ми також стикаємося з проблемою втрати GPS-сигналу в окремих регіонах через повітряні тривоги та вплив засобів радіоелектронної боротьби. У певні періоди система може втрачати кілька годин телеметричних даних протягом доби. Повністю усунути цю проблему на рівні інфраструктури наразі неможливо, тому ми вирішували її на рівні алгоритмів обробки та валідації даних. Платформа автоматично визначає такі дані як невалідні, виключає їх із розрахунків та не дає змогу використовувати для формування управлінської аналітики.
Для досягнення визначених бізнес‑показників систему спроєктували не як набір функцій, а як багаторівневу цифрову екосистему управління технічними ресурсами
— Якщо говорити загалом, наскільки складною виявилася розробка і чи повторили б ви цей шлях?
— Якщо чесно, я б відповіла: ні. І не тому, що це було неправильне рішення — навпаки. Просто це один із найскладніших проєктів як із технологічного боку, так і з погляду бізнес-архітектури, який реалізовувала команда AgriChain. За своєю архітектурою платформа нагадує високонавантажену систему, яка в режимі реального часу одночасно обробляє тисячі й мільйони телеметричних сигналів, операційних подій та бізнес-транзакцій.
Ми працюємо над цією платформою вже чотири роки й розуміємо, що як мінімум рік ще знадобиться для подальшого доопрацювання й адаптації окремих функціональних блоків у межах реальних виробничих циклів. Це безперервний процес розвитку, адже значна частина складних сценаріїв проявляється лише тоді, коли система починає працювати в масштабі великого операційного бізнесу та під реальним виробничим навантаженням.
— Наскільки дорогою виявилася власна розробка?
— Якщо говорити про інвестиції, то стартова вартість розробки становила орієнтовно 500 тис. доларів. Це суттєві вкладення, однак стратегічно — правильне рішення. Фактично йшлося не лише про створення кастомної ІТ-платформи. Паралельно команда була змушена переглядати, формалізувати й трансформувати внутрішні бізнес-процеси, а потім відображати їх у цифровому середовищі. Крім того, не всі процеси в компанії на той момент були достатньо структурованими і прозорими, тож впровадження системи фактично стало каталізатором їхньої стандартизації.
І, мабуть, головне відкриття цього проєкту для нас — навіть не сама технологія. У процесі розробки ми значно глибше зрозуміли власні виробничі та операційні процеси.
Для «Астарти» AgriChain Machinery стала не просто ІТ-рішенням, а інструментом комплексної трансформації операційного управління, який дав змогу інтегрувати виробничі процеси, логістику, контроль якості та управлінську аналітику в єдине цифрове середовище.