Розробка агропорталу: де розривається ручний облік заявок
Посівна стискає контур продажів у кілька тижнів: дилери розбирають насіння, добрива та засоби захисту, аграрії уточнюють залишки й терміни постачання, і будь-яка затримка з відповіддю означає перехід заявки до сусіднього постачальника.
Поки каталог продукції оптом живе в таблицях, розісланих по філіях і регіональних складах, менеджер збирає актуальні позиції вручну — на момент відправлення частина рядків уже не збігається з реальною наявністю.
Заявки при цьому надходять у месенджери, телефоном і на пошту. Формулювання дилерів не уніфіковані, фасування й одиниці виміру розходяться, тому та сама позиція заводиться в облік різними рядками, а частина позицій губиться між каналами.
Приймання заявок від дилерів перетворюється на передруковування: менеджер витрачає час на перенесення даних замість роботи з угодою, а друкарська помилка спливає вже на відвантаженні — з пересортицею та повторним узгодженням.
Звірка залишків вручну — друга точка розриву. Залишок змінюють одразу кілька потоків: відвантаження, бронювання під посівну, надходження від постачальників, повернення.
Поки дані зводять раз на день, дилер отримує підтвердження по позиції, якої фізично немає, логістика планує рейс під скасоване замовлення, а склад закриває розбіжність заднім числом.
Звідси й запит на b2b-портал для агробізнесу: не «кабінет заради кабінету», а єдиний контур, де каталог, складські залишки, ціни за договором і заявки працюють від одного джерела даних.
Розбираємо, як виглядає розробка агропорталу на практиці — і які вузькі місця вона закриває до старту сезону.
Що змінюється після запуску: час заявки, помилки, охоплення полів
До порталу заявка йшла через лист і дзвінок: менеджер переносив позиції в таблицю, звіряв залишки вручну й передзвонював за уточненням. Кожне уточнення — години простою й ризик, що клієнт піде до того, хто відповість швидше.
Після запуску заявка збирається в одній формі, а дані про клієнта та його поля підтягуються автоматично.
Швидкість обробки заявок і ціна помилки введення
Номенклатура обирається з єдиного каталогу, а не вводиться текстом; кількість перевіряється за доступним залишком, поля господарства підставляються з картки.
Частка заявок із помилкою введення падає в рази, а строк обробки скорочується з годин до хвилин — типове замовлення проходить цикл за один прохід, без проміжних дзвінків і переузгоджень.
Прозорість залишків, цін і умов для дилерів
Каталог і залишки синхронізуються з обліковою системою 1С, тому дилер бачить ту саму картину, що й менеджер, і не уточнює наявність телефоном. Ціни та умови підставляються за договором конкретного партнера: кожен бачить свою сітку та свою відстрочку без ручних вивантажень.
Якщо до порталу підключено супутниковий моніторинг полів, історія обробки ділянки лежить поруч із замовленням — менеджер пропонує рішення за фактичним станом посівів, а не за загальними словами, і охоплення полів в одній угоді зростає.
Як реалізувати портал: коробка, платформа, індивідуально
Три варіанти відрізняються не обсягом робіт, а тим, де проходить межа вашої логіки та даних.
Готове галузеве рішення закриває типовий сценарій, налаштування платформи розширює його під ваші довідники, а індивідуальне складання починається там, де агрономічна логіка перестає бути типовою.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готове галузеве рішення | Каталог, заявки, особистий кабінет агронома за типовим сценарієм | Нестандартні розрахунки та довідники вендор не підтримає |
| Налаштування платформи | Ядро закриває більшість завдань, потрібні свої ролі та обмін з 1С | Є стеля за глибиною доопрацювань, оновлення вендора їх зачіпають |
| Індивідуальне складання | Своя агрономічна логіка, шари NDVI, високе навантаження | Довший вихід на перший реліз, розвиток залишається за командою |
Коли галузевого готового рішення достатньо
Якщо портал повторює типовий сценарій — каталог із фільтрами за культурами, заявки, історія замовлень, — готове рішення знімає більшу частину роботи. Залишається налаштувати довідники, ролі та права доступу під структуру господарств.
Коли без індивідуального складання не обійтися
Своя обробка полів, розрахунок норм внесення, зв'язка шарів NDVI з картами господарств і обмін з 1С потребують коду, а не перемикачів. У коробці такі розрахунки робляться обхідними шляхами й ламаються за першої зміни довідника — тому ділянку збирають окремо.
Етапи робіт: від аудиту процесів до передачі порталу
Роботу ведемо ітераціями й починаємо не з коду, а з процесів: поки не описано, як запит дилера перетворюється на відвантаження, будь-який інтерфейс буде вгадуванням. Нижче — послідовність, яку проходимо на агропорталі, з точками контролю на кожному кроці.
Аудит продажів і схема даних
- Аудит процесів продажів: розбираємо з менеджерами та агрономами шлях від запиту дилера до відвантаження — де дублюються заявки, хто узгоджує ціни, на якому кроці губиться історія за конкретним полем.
- Схема даних: фіксуємо довідники культур і сортів, номенклатуру, партії, межі полів і вегетаційні шари, правила зв'язків між ними. Схема стає контрактом для зберігання, вивантажень і прав доступу.
- Прототип каталогу: клікабельний прототип із фільтрами за культурою, регіоном і фазою вегетації перевіряємо на реальних позиціях, а не на вигаданих прикладах.
Узгодження ролей і сценаріїв із замовником
- Матриця ролей: узгоджуємо, що бачить дилер, агроном, менеджер і логіст, до початку розробки — інакше доступи доведеться переробляти разом із логікою.
- Налаштування обміну з обліковою системою: двосторонній обмін номенклатурою, залишками та статусами замовлень, черга повторного відправлення й журнал розбіжностей. Якщо обліковий контур недоступний, портал продовжує приймати замовлення.
- Приймальні перевірки: проганяємо сценарії закупівлі, повернення та коригування, звіряємо залишки й ціни з обліковою системою, перевіряємо відкат на попередню версію.
- Передача порталу: документація, регламент оновлень, навчання співробітників і видача доступів.
Комплект постачання: доступи, схеми даних, регламенти
Комплект постачання — це не папка абстрактних описів, а робочі артефакти: за ними новий інженер вводиться в проєкт за день, а підтримка закриває звернення, не розшукуючи автора коду. Документація оновлюється разом із релізом — застарілі схеми не потрапляють до замовника.
Документація, схеми та інструкції
- Схема інтеграції з 1С: напрямок обміну, склад довідників, період синхронізації, правила розв'язання конфліктів при розбіжності залишків і цін.
- Модель даних порталу: сутності каталогу, зв'язки карток товарів із культурами, регіонами та контрагентами, обов'язкові та обчислювані поля.
- Регламент обробки заявок: маршрути заявки від агронома й роздрібного клієнта, строки реакції на кожному кроці, правила ескалації при простроченні та передачі зміни.
- Інструкції для менеджерів: покрокові сценарії — публікація позиції в каталозі, заведення агронома, робота з шарами NDVI на карті полів, вивантаження звіту.
- Документація середовища: склад серверів і сервісів, схема резервного копіювання, порядок розгортання та відкат попереднього складання.
- Журнал технічних рішень: чому обрано конкретний варіант обміну, щоб суперечка не відкривалася заново на кожному доопрацюванні.
Матриця ролей і правила доступу
- Матриця ролей і прав: перелік ролей — агроном, менеджер каталогу, адміністратор порталу, інтеграційний сервіс — і дозволені дії для кожної.
- Правила доступу: двофакторна автентифікація для адміністративних ролей, розділення прав адміністратора порталу й адміністратора обміну, журналювання змін у каталозі та налаштуваннях.
- Порядок передачі доступів: власники облікових записів, дії при звільненні співробітника, зберігання резервного доступу в замовника.
Комплект залишається у вас: підтримку можна вести своїми силами, передати іншій команді або доручити нам.
Кейс: дилерський портал замість таблиць і пошти
Агровиробник із мережею дилерів у кількох регіонах вів замовлення в таблицях, які пересилалися поштою між менеджерами. Каталог продукції, залишки та ціни жили окремими файлами, а облікова система на платформі 1С оновлювалася вручну.
Як було до запуску
Дилер надсилав заявку листом, менеджер вручну переносив її в таблицю, а потім в облікову систему — одне замовлення проходило через три-чотири руки. Узгодження займало від двох робочих днів, а в розпал сезону черга розтягувала його до тижня.
Приблизно кожна восьма позиція заводилася з помилкою: не той склад, застаріла ціна або дубль за клієнтом.
Що змінилося після
Заявка тепер оформлюється в особистому кабінеті дилера й одразу перевіряється за залишками, цінами та лімітами. Строк обробки скоротився до кількох годин, частка помилок введення — нижче відсотка, а кількість підключених дилерів зросла втричі без розширення штату менеджерів.
Пішов цілий клас відмов: коли замовлення підтверджено, а товару на складі немає. Каталог, залишки та статуси відвантажень читаються безпосередньо з облікової системи, тому дилер бачить актуальну картину й не звіряє файли.
Пізніше до порталу додали NDVI-моніторинг полів: дилер бачить стан посівів у своїх клієнтів і приходить із готовим запитом на засоби захисту.
Що робити, якщо каталог уже ведуть в 1С і таблицях?
Якщо каталог живе в обліковій системі й паралельно в таблицях, корінь проблеми — не в таблицях, а у відсутності майстер-системи для номенклатури.
Поки її не призначено, кожна правка ціни або групи товарів розходиться по двох базах, а заявка надходить на позицію, якої в обліку вже немає. Тому перенесення каталогу починається не з вивантаження, а з рішення: хто володіє довідником, а хто його лише відображає.
| Яка система головна | Що це дає | Чим платимо |
|---|---|---|
| Облікова система | Номенклатура й ціни приходять на портал з одного джерела, ручна звірка зникає | Вітринні поля та фільтри потрібно пов'язати з обліковими реквізитами |
| Портал | Каталог ведуть агрономи: описи, культури, регіони, партії | З'являється узгодження перед постановкою позиції на облік |
| Двосторонній обмін | Заявки, статуси та залишки рухаються в обидва боки | Потрібні правила розв'язання конфліктів і журнал змін, інакше розбіжності накопичуються мовчки |
Вибір не бінарний: майстер-система з номенклатури й цін одна — зазвичай це 1С, — а портал залишається джерелом заявок і клієнтських даних. Зворотний запис виправданий там, де портал породжує облікові сутності: заявку, резерв, рахунок.
Далі — поетапний перехід без зупинки продажів: спочатку синхронізація довідників в один бік, потім період звірки розбіжностей за журналом обміну, потім перенесення каталогу на портал і лише після цього вмикання зворотного запису. Подвійне введення даних зникає поступово, а продажі не зупиняються ні на день.
Технічні питання: доступи, навантаження, інтеграції
Технічні сумніви навколо агропорталу майже ніколи не стосуються зовнішнього вигляду вітрини — вони стосуються того, як система поводиться в розпал сезону: коли агрономи працюють із поля, постачальники масово оновлюють прайси, а облікові дані мають зійтися. Нижче — відповіді на те, що найчастіше уточнюють перед стартом проєкту.
Розмежування прав, стійкість до піків, обмін з обліковою системою та відновлення після збою проєктуються до першого рядка коду: їхня переробка на працюючій системі коштує дорожче, ніж акуратне закладання на старті.
Як розмежовуються ролі та права доступу?
Одразу закладаємо модель ролей: агроном, менеджер закупівель, постачальник, трейдер, аналітик. Права призначаються на рівні розділів і окремих полів — польові дані однієї агрогрупи не видні сусідній, постачальник править лише свій каталог. Кожна дія з ціною або статусом заявки пишеться в журнал: видно, хто і коли змінив запис.
Що відбувається з порталом під час посівної та збиральної?
Пік навантаження припадає на вузькі сезонні вікна: масові заявки, фотографії з поля, вивантаження звітів. Каталог віддається з кешу, важкі експорти йдуть у чергу, звітність читається з окремої репліки — вітрина не гальмує через аналітику. Профіль сезонного піку відтворюваний навантажувальним тестом до запуску.
Як влаштований обмін з обліковою системою?
1С залишається майстром за довідниками, партіями та взаєморозрахунками, портал — за заявками та даними моніторингу. Обмін іде за розкладом і за подіями, записи позначаються ключем повторного відправлення, тому збій зв'язку не створює дублів. Розбіжності складаються в окремий журнал для розбору, а не губляться мовчки.
Як робиться резервне копіювання та відновлення?
Повна копія бази знімається щодня, зміни — частіше, копії зберігаються поза основним контуром. Раз на регламентний строк ми розгортаємо копію на тестовому стенді й перевіряємо цілісність зв'язків: неперевірена копія — це не гарантія, а надія. Відновлення до робочого стану вимірюється хвилинами, а не добами.
Наскільки повноцінна мобільна версія?
Мобільні сценарії — основні для поля, тому адаптив проєктуємо не як урізану копію: зйомка фото, короткі форми, робота при слабкому каналі з чернетками та досиланням при появі зв'язку.
Десктопний і мобільний інтерфейси живуть на одній кодовій базі, тому нова функція одразу доступна на обох.
Обговоримо розробку агропорталу під ваші процеси
Щоб повернутися з оцінкою строків і планом робіт, а не із загальними формулюваннями, потрібен стартовий набір даних. Чим конкретніші ввідні, тим точніше розбиття за етапами й менше переробок у середині розробки. Нижче — що запитуємо на першій розмові.
- Ролі та сценарії: агроном, менеджер, дилер, логіст — хто що бачить і які дії виконує: заявка, замовлення, узгодження, відвантаження.
- Каталог і номенклатура: поточне джерело даних, обсяг позицій, атрибути — культура, фасування, регіон допуску, правила фільтрації та пошуку.
- Моніторинг полів: звідки надходять знімки, у якому вигляді зберігаються, які вегетаційні індекси та карти потрібні на виході.
- Інтеграції: облікова система (1С або інша), склад, платежі, система роботи з клієнтами — що читаємо, куди пишемо, як видаються доступи.
- Контур розміщення та вимоги до безпеки: ваш сервер або хмара, хто з боку замовника узгоджує макети й приймає етапи.
- Плани розвитку: що має з'явитися після запуску — це визначає архітектуру та те, що закладаємо одразу.
На виході — план робіт і етапи з орієнтовними строками, склад команди та порядок приймання. Окремо проговорюємо передачу порталу в підтримку: регламент оновлень, моніторинг доступності, порядок обробки звернень. Опишіть задачу — повернемося з оцінкою та планом.
