Покрокова демонстрація 13 агентів: зерно, експорт і комбікорм
Це супровідна інструкція до живої демонстрації. Демонстрація не відео і не презентація, а робочий кабінет агентів на демонстраційних даних: елеватор на 120 тисяч тонн, кластер полів, комбікормовий завод, експортні партії і порт. Тут зібрані всі 19 сценаріїв і всі 125 кроків з кадрами екранів, щоб можна було подивитись зміст, не проходячи все підряд, і перейти одразу на потрібний крок.
Як користуватись демонстрацією
- Стрілки «назад» і «далі» внизу екрана або клавіші ← →. Можна тиснути прямо по підсвіченій частині екрана.
- Кнопка «Кроки» показує весь сценарій, будь-який крок відкривається одним кліком.
- На кроках зі значком «можна ввести своє» приклад замінюється вашими цифрами, і далі по сценарію все перераховується.
- Кнопка «Поділитись» копіює адресу саме цього кроку, щоб надіслати колезі.
- Клавіша P вмикає режим презентації: ховає бічну панель і збільшує шрифт для показу на екрані.
- Місце, де ви зупинились, зберігається. Можна закрити вкладку і повернутись пізніше.
Важливо про цифри
Усі елеватори, поля, партії, водії, покупці, перевізники, постачальники, ціни і рецептури в демонстрації умовні. Це приклад, зібраний під зерновий і кормовий контур агрохолдингу. Жодних реальних даних жодного клієнта тут немає, і саме тому кожен екран підписаний як приклад. На реальному прогоні всі ці екрани заповнюються вашими цифрами з ваших систем.
Машина з поля: від в'їзду на ваги до накладної і залишку в силосі
Наскрізний сценарій без пропусків проміжних кроків
Агенти: облік на елеваторах, якість зерна на елеваторі, логістика зерна
Що показує цей сценарій
Показує головне: одна партія проходить весь ланцюг без жодного повторного ручного вводу, а кожна цифра в накладній має джерело, яке можна відкрити. Це і є різниця між обліком у книзі і обліком, з якого можна рахувати гроші.
- Одні й ті самі дані вводяться тричі
- Розбіжність з господарством випливає через тижні
- Помилку в одному рядку не бачить ніхто до звірки

- Заявка на рейс і GPS транспорту
- Темп розвантаження на кожній вазі за останню годину
- Культура визначає вагу, бо ріпак і пшеницю не змішують у потоці

- Брутто з вагового терміналу, не з блокнота
- Номер авто з камери, ТТН з фото або з електронної форми
- Поле і культура з довідника облікової системи за номером ТТН

- Показники з приладів лабораторії, а не з голосу
- Базис береться з договору складського зберігання
- Кожен показник має час вимірювання і номер проби

- Одна проба нічого не доводить, ряд доводить
- Різниця однакова по всіх машинах з поля, значить справа не в партії
- Наступний крок це перевірка приладу, а не претензія людям

- Усушка рахується за вологою понад базис
- Очистка рахується від залишку після усушки, а не від фізичної ваги
- Пункти договору 4.2 і 4.3 підставлені в розрахунок, а не переказані словами

- Жодного повторного вводу
- Номер проби і час вимірювання лишаються в паспорті
- Паспорт одразу прив'язаний до силосу, куди пішла партія

- Культура і клас мають збігатись, інакше партія знеособлюється
- Волога вище базису означає окремий силос під сушіння
- Місткість рахується з урахуванням машин, які ще їдуть на цю культуру

- Залишок у фізичній і в заліковій вазі одночасно
- Свої і сторонні поклажодавці рознесені
- Кожна партія клікається до конкретної машини і проби

- Одне джерело для всіх трьох документів
- Номер і дата присвоюються за вашою нумерацією
- Підпис лишається за людиною, агент документ не проводить

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

- Різні адресати отримують різні повідомлення, а не одну розсилку
- У кожному повідомленні є цифра і дія, а не «зверніть увагу»
- Кнопки це підтвердження людини, а не інформування

- Кожна цифра має джерело і час отримання
- Видно, що агент зробив сам, а що підтвердила людина
- Журнал зберігається разом з партією, а не окремо

- 214 машин за добу, 5 380 тонн
- Розбіжності з господарствами видно того самого дня
- Вагова більше не зводить книгу ввечері

Підсумок
Оформлення однієї машини скоротилось з 6 хвилин до 40 секунд підтвердження. За добу через ваги проходить 214 машин, тобто звільняється близько 20 годин роботи вагової на добу в пік. Розбіжність з господарством видно того самого дня, а не під час звірки в жовтні.
Що потрібно, щоб це працювало на реальних даних
- Дані ваг: або вивантаження, або підключення до вагового терміналу.
- Дані лабораторії: LIMS або файл журналу лабораторії.
- Довідник полів і культур з облікової системи.
- Коефіцієнти усушки і очистки з договору складського зберігання.
- Одна людина з елеватора, яка підтверджує паспорти партій у перші два тижні.
Спірна проба: господарство і елеватор бачать різні цифри
Найчастіший конфлікт у жнива і як агент його закриває цифрами
Агент: якість зерна на елеваторі
Що показує цей сценарій
Показує, що агент не стає ні на чий бік. Він піднімає ряд вимірювань, знаходить системну причину розбіжності і переводить суперечку з розмови про довіру в розмову про прилад.
- Претензія усна, без номерів проб
- Обидві сторони впевнені у своїх приладах
- Поки спір триває, машини їдуть далі

- Проба 04-1182, три точки по кузову
- Прилад повірений, свідоцтво чинне
- Показники не редагувались після збереження

- Чотири машини з одного поля, зсув 0,9 у кожної
- Машина з іншого поля має зсув 0,1
- Якби справа була в партії, зсув гуляв би, а він стабільний

- Показник лабораторії агент не редагує в жодному режимі
- Заліковка не перераховується заднім числом без рішення людини
- Задача має відповідального і строк

- Рахунок іде на фактичну кількість машин з поля
- Показані обидва варіанти, з поточною вологою і з вологою току
- Цифра порахована формулою договору, а не на око

- Одна відповідь замість двох днів листування
- Задача видна обом сторонам
- Правило на майбутнє зафіксоване тут же

- Розбіжність рахується автоматично по кожному полю
- Причини розкладені на складові
- За сезон таких випадків 34, жоден не дійшов до рівня директорів

Підсумок
Спір закритий за 12 хвилин замість двох днів листування. Причину знайдено, вологомір на току відправлено на калібрування. За сезон таких випадків було 34, вони перестали доходити до рівня директорів.
Що потрібно, щоб це працювало на реальних даних
- Журнал лабораторії елеватора з номерами проб і часом.
- Дані вологоміра на току, навіть у вигляді фото журналу.
- Правило, чия проба є остаточною, з договору складського зберігання.
- Відповідальний за калібрування приладів на боці господарства.
Пік жнив: 38 машин, дві ваги і черга, якої не має бути
Планування вивезення поле, елеватор, порт
Агент: логістика зерна
Що показує цей сценарій
Показує, що вузьке місце в жнива це не кількість машин, а пропускна здатність ваг. Агент планує від ваг назад до комбайна, а не навпаки.
- План живе в голові диспетчера
- Черга на вагах ніде не рахується
- Простій комбайна і простій машини це дві різні втрати, і обидві невидимі

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

- Вага №1 працює на пшеницю, вага №2 на решту культур
- Ріпак і пшеницю не змішують у потоці
- Вікно це не жорсткий графік, а пріоритет: якщо намолот пішов швидше, план перебудовується

- Простій рахується з GPS і з протоколів ваг, а не зі слів
- Простій комбайна перерахований у втрачені тонни намолоту
- Це база для розмови з перевізниками про подачу

- Прогноз погоди по конкретних полях, а не по району
- Перекидаються тільки ті машини, які встигнуть повернутись
- Зерно з дощу піде на окремий силос під сушіння, це вже враховано у вікнах

- Накопичення в порту під судно має свій строк
- Комбікормовий завод має добову потребу і обмежений склад
- Силос це не склад назавжди, це буфер між двома потоками

- Водій отримує час і вагу, а не загальний графік
- Диспетчер бачить відхилення, а не всі рейси
- Будь-яка зміна плану проходить через людину

Підсумок
Середнє очікування на вагових впало з 52 до 6 хвилин. Простій комбайнів через відсутність транспорту скоротився на 71 відсоток. Тими самими 38 машинами вивозиться на 14 відсотків більше зерна за добу.
Що потрібно, щоб це працювало на реальних даних
- GPS або телеметрія транспорту, хоча б у вигляді точок раз на 5 хвилин.
- Дані ваг про фактичний темп приймання.
- Намолот по полях, навіть орієнтовний, від агронома або з комбайнів.
- Диспетчер, який приймає план і має право його змінювати.
Скільки кукурудзи в корм, а скільки на продаж
Рішення, у якому дві правди: виробнича і комерційна
Агент: баланс зерна
Що показує цей сценарій
Показує рішення, яке зазвичай ухвалюється на нараді з двома різними таблицями в руках. Агент зводить обидві сторони в один баланс і рахує ціну кожного варіанта.
- Дані живуть у трейдингу, на елеваторах, на заводах і в агрослужбі
- Кожна служба має свою правду і свій горизонт
- Поки таблиці зводяться, ринок змінюється

- Горизонт до кінця сезону, а не до кінця місяця
- Потреба заводів береться з плану виробництва кормів
- Продане береться з контрактів, а не з намірів

- Ціна продажу зараз проти прогнозної ціни закупівлі взимку
- Врахована логістика і вартість зберігання
- Ризик прогнозу врожаю показаний окремо, він не схований у середньому

- Ефект це не «економія», а різниця між двома реальними рішеннями
- Врахована вартість зберігання власного зерна
- Ризик прогнозу врожаю винесений окремим рядком

- Розрахунок агент робить сам і щотижня
- Рішення про розподіл ухвалює директор департаменту
- Зміна плану виробництва кормів це окреме погодження

- Рішення зберігається з версією розрахунку
- Через квартал агент сам повертається з фактом
- Це і є навчання на ваших даних, а не на середніх по ринку

Підсумок
Баланс перераховується щотижня замість раз на квартал. Обсяг закупівлі кукурудзи ззовні впав на 18 тисяч тонн за сезон, бо власне зерно перестало продаватись у моменти, коли завод за місяць купував таке саме.
Що потрібно, щоб це працювало на реальних даних
- Прогноз урожаю по культурах від агрослужби.
- План виробництва комбікормів на сезон.
- Залишки на елеваторах і на заводах.
- Контрактна позиція трейдингу: що вже продано і на яких умовах.
- Правило, хто ухвалює рішення про розподіл і в якому форматі.
Вікно продажу: чотири пропозиції і одна приведена ціна
Котирування, базиси і те, що реально залишиться на елеваторі
Агент: зерновий трейдинг
Що показує цей сценарій
Показує, що порівнювати котирування безглуздо. Порівнювати можна тільки приведену ціну на елеваторі, порахувану однаково для всіх пропозицій, разом з умовами оплати.
- Котирування з джерела, яким ви користуєтесь
- Прогноз будується на експорті, курсі і сезонності, а не на «схоже на зростання»
- Зелена смуга це ваш цільовий коридор, а не думка агента

- Базис визначає, хто платить за логістику і перевалку
- Відстрочка це вартість грошей, а не дрібниця
- Обсяг і строк поставки теж входять у порівняння

- Автологістика до порту за фактичною ставкою тендера
- Перевалка і лабораторія порту за вашими договорами
- Вартість грошей рахується за вашою ставкою залучення, а не за середньою по ринку

- Позиція рахується в тоннах і у відсотках від прогнозного врожаю
- Прогноз врожаю має похибку, і вона показана окремо
- Рекомендація прив'язана до вашої політики продажів, а не до відчуття ринку

- Сигнал містить приведену ціну, а не котирування
- Вказаний строк дії пропозиції
- Кнопка це фіксація рішення, а не підписання контракту

- Приведена ціна рахується автоматично і завжди однаково
- Рішення про продаж ухвалює людина
- Контракт підписує людина, агент готує документи після рішення

- Збережені котирування на момент рішення
- Збережена версія тарифів логістики і перевалки
- Видно, хто ухвалив рішення і о котрій годині

Підсумок
Порівняння чотирьох пропозицій займає хвилину замість половини дня в Excel. За сезон агент підсвітив 9 вікон продажу, з них 6 використані. Найдорожча пропозиція виявилась не найвигіднішою в трьох випадках з чотирьох.
Що потрібно, щоб це працювало на реальних даних
- Джерело котирувань, яким ви користуєтесь зараз.
- Тарифи логістики: авто, вагони, перевалка в порту.
- Ваші базиси і типові умови контрактів.
- Контрактна позиція: що вже продано і на яких умовах.
- Правило, з якого моменту сигнал стає рішенням і хто його ухвалює.
Тендер на 200 рейсів у порт за 40 хвилин
Ставка це не єдина колонка, і агент це показує
Агент: freight-закупівля перевезень
Що показує цей сценарій
Показує, що дешева ставка від перевізника, який не подає машини вчасно, коштує дорожче за дорогу. Агент рахує ставку разом з історією виконання і з ризиком демереджу.
- Обдзвін займає до двох днів
- Порівнюється тільки ставка
- Історія зривів ніде не зафіксована

- Обсяг береться з плану накопичення під судно
- Дати прив'язані до laycan судна, а не до «якнайшвидше»
- Вимоги до транспорту з ваших правил, включно з пломбами

- Розсилка в месенджер і на пошту одночасно
- Відповідь у вільній формі, агент її розбирає
- Уточнення агент задає сам, якщо в відповіді бракує даних

- Виконання рейсів це факт з минулого сезону, а не думка
- Затримки рахуються в годинах, бо вони конвертуються в демередж
- Оцінка це формула, і її видно нижче

- Демередж це не абстрактний ризик, це рядок у контракті
- Імовірність береться з фактичного виконання перевізника
- Формула проста і показана повністю

- Основний обсяг надійному перевізнику
- Частина дешевому, але з датами, які не критичні
- Резерв на новому перевізнику, щоб перевірити його малим обсягом

- Тендер, збір, порівняння і рекомендація це агент
- Затвердження результату це людина
- Після затвердження агент сам ставить завдання і стежить за подачею

Підсумок
Тендер на рейси проходить за 40 хвилин замість двох днів обдзвону. Середня ставка впала на 6,4 відсотка, а зрив подачі скоротився втричі, бо лот тепер ділиться між двома перевізниками, а не віддається одному.
Що потрібно, щоб це працювало на реальних даних
- Перелік перевізників з контактами в месенджері або на пошті.
- Історія рейсів за минулий сезон, навіть у вигляді таблиці.
- Ваші вимоги до транспорту: тип кузова, пломби, документи.
- Правило, хто затверджує результат тендера і в якому діапазоні ставок.
Судно, вагони і вікно порту: три календарі, які ніхто не зводить
Накопичення партії під laycan без демереджу
Агент: експортна логістика
Що показує цей сценарій
Показує конфлікт, який зазвичай виявляється в день подачі: вагони подані, судно зсунулось, у порту немає місця під накопичення. Агент бачить це за пʼять днів і дає варіанти.
- Судно, вагони і термінал ведуть різні люди
- Спільної картини немає ніде
- Конфлікт виявляється в день подачі

- Судно з даних лінії або агента, а не з листа тижневої давнини
- Вагони з заявок на подачу
- Вікно порту з договору з терміналом

- Готовність рахується від фактичного накопичення в порту
- Документи входять у готовність, бо без них судно не вийде
- Ризик рахується, а не ставиться логістом на око

- ETA судна з даних лінії, оновлення сьогодні о 06:40
- Вікно порту з договору з терміналом
- Вагони вже в дорозі, їх не можна просто зупинити

- Ціна кожного варіанта порахована за вашими договорами
- Врахований ризик, а не тільки прямі витрати
- Рекомендація має підставу, а не інтуїцію

- Лист терміналу готує агент, підписує людина
- Завдання перевізникам оновлюються автоматично
- Нова контрольна точка ставиться на дату, коли рішення треба перевірити

- 11 діб демереджу минулого сезону проти 2 у цьому
- Конфлікти знаходяться в середньому за 5 днів
- Заявки на вагони більше не пропускаються

Підсумок
Демередж за сезон скоротився з 11 діб до 2. Накопичення під судно почало плануватись за 8 днів, а не за 3. Конфлікти між вагонами, автотранспортом і вікном порту виявляються заздалегідь, а не в момент подачі.
Що потрібно, щоб це працювало на реальних даних
- Контрактна позиція з базисами і laycan.
- Дані по подачі вагонів або доступ до заявок перевізника.
- Графік вікон порту і залишки на терміналі.
- Залишки на елеваторах з розбивкою по культурах і класах.
- Людина в експортній логістиці, яка приймає план і має право його змінювати.
Комплект документів: сім форм і одна розбіжність у вазі
Те, що зазвичай знаходять у порту, знаходиться на елеваторі
Агент: відвантажувальні документи
Що показує цей сценарій
Показує, що документ це не текст, а звірка. Агент збирає комплект з даних, які вже є, і ловить розбіжності між документами до того, як їх знайде сюрвеєр або банк.
- Кожен документ має своє джерело даних
- Жоден не набирається руками з нуля
- Сірий статус означає, що джерело ще не дало дані, а не що агент забув

- Умови беруться з тексту контракту, з номером пункту
- Перевіряються допуски по кількості і якості
- Перевіряється перелік документів, який вимагає покупець і банк

- Вага з ваг терміналу і вага з драфт-сюрвею завжди відрізняються
- Контракт визначає, яка з них є остаточною, і агент це перевіряє
- Розбіжність ловиться до відправки документів, а не після

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

- Усі поля з джерел, жодного ручного вводу
- Виправлення підсвічені, а не приховані
- Підпис лишається за уповноваженою особою

- Відправка через ваш кабінет ЕДО або пошту, без нових систем
- Агент бачить, що комплект отримано, а не просто відправлено
- Якщо підтвердження немає більше доби, агент нагадує сам

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

Підсумок
Підготовка комплекту скоротилась з 4 годин до 25 хвилин на партію. За сезон агент знайшов 46 розбіжностей, з них 9 таких, що зупинили б оплату за акредитивом.
Що потрібно, щоб це працювало на реальних даних
- Шаблони ваших документів і хто їх підписує.
- Контракти з умовами: базис, допуски, вимоги до сертифікатів.
- Дані ваг, лабораторії і паспортів партій.
- Доступ до кабінету ЕДО або пошти, якою документи відправляються.
- Людина, яка підписує комплект, з нормальним строком реакції.
Затримка в дорозі: коли покупець дізнається про це від нас
Відстеження судна і рефконтейнерів з реакцією, а не з червоним кружечком
Агент: track and trace експорту
Що показує цей сценарій
Показує різницю між трекінгом і агентом. Трекінг фарбує рядок червоним. Агент розуміє наслідок для конкретного клієнта і проходить ланцюг до кінця.
- Статус є, наслідку немає
- Хто з клієнтів постраждає, невідомо
- Реакція починається тоді, коли клієнт сам питає

- Події з даних лінії, а не з листування
- Кожна точка має планову і фактичну дату
- Наслідок для контракту рахується одразу

- Температурний лог з даних лінії, а не зі слів
- Порівняння з вимогою контракту, а не з середньою нормою
- Будь-яке відхилення фіксується з часом і тривалістю

- Порівняння з іншими контейнерами того самого рейсу
- Історія затримок на цьому вузлі перевалки
- Відхилення в годинах, а не «затримується»

- Клієнт дізнається від нас, а не від лінії
- Наслідки для контракту перевіряються за текстом контракту
- Кожна дія має час і результат

- Лист готує агент, підписує і відправляє менеджер
- У листі є все, що клієнт спитав би у відповідь
- Тон нейтральний, без виправдань і без канцеляриту

- Клієнт попереджений у середньому за 31 годину до планової дати
- Претензій за несвоєчасне повідомлення немає
- Вузли перевалки з системними затримками видно і враховуються в контрактах

Підсумок
Клієнт дізнається про затримку від нас, а не від лінії, у середньому за 31 годину до планової дати. Кількість претензій за несвоєчасне повідомлення впала до нуля за сезон.
Що потрібно, щоб це працювало на реальних даних
- Доступ до даних лінії або трекінгового сервісу, яким ви користуєтесь.
- Дані по рефконтейнерах: температурні логи від лінії.
- Контракти з умовами про строки і повідомлення.
- Контакти клієнтів і правило, хто з ними спілкується.
Мікотоксини в кукурудзі: партію не блокують, її перенаправляють
Вхідний контроль, який не зупиняє завод і не псує стадо
Агент: якість кормової сировини
Що показує цей сценарій
Показує, що правильне рішення по партії це не «прийняти або не прийняти». Партія з підвищеним ДОН непридатна для стартового корму і цілком придатна для фінішера, і саме це агент рахує за секунди.
- Показники з приладів лабораторії
- Норми з вашого стандарту, окремі для кожного виду корму
- Порівняння відбувається до розвантаження, а не після

- Норма на кожен вид корму своя, і вона з вашого стандарту
- Обмеження вводу рахується так, щоб у готовому кормі ДОН лишався в нормі
- Партія фізично одна, а рішень по ній може бути кілька

- Блокування це статус партії, а не усна домовленість на вагах
- Підтверджує людина, і це видно в журналі
- Якщо хтось спробує взяти цю партію в старт, система не дасть

- Історія по кожному постачальнику накопичується сама
- Тренд рахується, а не оцінюється на око
- Рекомендація адресна: до кого і з чим іти

- Рахується вартість самої партії плюс зворотна логістика
- Плюс ризик простою заводу, якщо повернень багато
- Проти цього стоїть нуль, бо перенаправлення нічого не коштує

- Кожен отримує тільки те, що стосується його рішення
- Повідомлення містить дію, а не факт
- Кнопки це підтвердження, після якого агент діє далі

- Блокування партії це автоматична дія
- Дозвіл на ввід це рішення технолога
- Зміна норм це рішення служби якості

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

- Довжина смуги це доби покриття
- Позначка це строк поставки по кожній позиції
- Все, що коротше за свій строк поставки, вже проблема

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

- Без руху означає нуль витрати за період, а не малу витрату
- Строк придатності рахується разом із залишком
- Пропозиція конкретна, а не «розібратись»

- Добова витрата рахується від обсягу виробництва і норми вводу
- Покриття це залишок поділити на витрату
- Точка замовлення це строк поставки плюс страховий запас

- Розрахунок і заявка це агент
- Підтвердження заявки це людина
- Автоматичне замовлення в межах суми це окреме рішення після пілота

Підсумок
Зупинок лінії через відсутність інгредієнта не було жодної за півроку. Залежі скоротились на 41 відсоток, бо агент бачить позиції без руху так само добре, як дефіцит.
Що потрібно, щоб це працювало на реальних даних
- Залишки на складах заводів.
- План виробництва кормів на місяць уперед.
- Норми вводу з рецептур.
- Строки поставки по кожному постачальнику, хоча б орієнтовні.
- Правило, хто ініціює позачергову закупівлю і в яких межах.
Соєвий шрот подорожчав на 9 відсотків: рецептура за 40 секунд
Дешевша тонна при тій самій поживності, а не замість неї
Агент: least-cost рецептури комбікорму
Що показує цей сценарій
Показує головне заперечення до least-cost і відповідь на нього. Дешевший корм має сенс тільки тоді, коли жодне зоотехнічне обмеження не порушене, і агент показує кожне з них до і після.
- Ціни з ваших контрактів і з ринку одночасно
- Поріг спрацювання 3 відсотки, він налаштовується
- Перерахунок запускається сам, без прохання технолога

- Склад з вашої діючої рецептури, а не з довідника
- Вартість тонни рахується за цінами з логістикою до заводу
- Обсяг береться з плану виробництва на місяць

- Обмеження з ваших зоотехнічних вимог, а не з підручника
- Мінімуми і максимуми окремо, бо порушення в обидва боки шкідливе
- Якщо задача не має розв'язку в межах обмежень, агент так і каже

- Ріпаковий шрот увійшов у межах вашого максимуму 4 відсотки
- Амінокислоти дорогі, але їх треба мало, і це часто дешевше за шрот
- Кукурудза власна, тому її ціна це собівартість, а не ринок

- Обсяг береться з плану виробництва, а не з потужності заводу
- Врахована різниця в логістиці інгредієнтів
- Ефект по всіх рецептурах рахується окремо, бо не всі змінились

- Технолог бачить обмеження до і після, а не тільки склад
- Показані ті два показники, що підійшли до межі
- Підтвердження це рішення, яке записується разом з версією рецептури

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

- Збережені ціни всіх інгредієнтів на момент розрахунку
- Збережені обмеження тієї редакції
- Видно, хто підтвердив і що змінив перед підтвердженням

Підсумок
Рецептури перераховуються при кожній зміні ціни інгредієнта більше ніж на 3 відсотки, а не раз на квартал. Середня вартість тонни впала на 248 гривень при незмінних показниках поживності і незмінному прирості.
Що потрібно, щоб це працювало на реальних даних
- Ваші рецептури з нормами вводу і обмеженнями.
- Зоотехнічні вимоги по кожному виду корму.
- Актуальні ціни інгредієнтів, включно з логістикою до заводу.
- Наявні запаси і те, що вже законтрактовано.
- Технолог, який підтверджує кожну нову версію рецептури.
Контрактувати шрот зараз чи чекати: сигнал з підставою
Вікно закупівлі під фактичну потребу, а не під відчуття ринку
Агент: закупівля кормової сировини
Що показує цей сценарій
Показує, що рекомендація без підстави це ворожіння. Агент показує кожен сигнал, його джерело і вагу в рішенні, тому з ним можна сперечатись предметно.
- Потреба з плану виробництва на 3 місяці вперед
- Покрито це підписані контракти, а не домовленості
- Відкрито це ціновий ризик у тоннах

- Історія цін з вашого джерела
- Прогноз будується на сигналах, кожен з яких видно
- Коридор прогнозу показує невизначеність, а не одну цифру

- Сигнали різнорідні, і це нормально
- Вага кожного налаштовується разом з вами
- Сигнали, що суперечать висновку, теж показані, а не приховані

- Варіант «нічого не робити» показаний завжди, з його ціною
- Врахований ліміт складу, а не тільки гроші
- Рекомендація прив'язана до вашої політики покриття

- Ціна з доставкою на завод, а не зі складу постачальника
- Історія якості з агента вхідного контролю
- Ліміт на контрагента перевіряється до фіксації

- Ліміт на контрагента перевіряється до фіксації
- Контракт готує людина, агент готує вхідні дані
- Прогноз перевіряється фактом, і це видно

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

Підсумок
Частка законтрактованої потреби зросла з 41 до 68 відсотків. Середня ціна закупівлі соєвого шроту за сезон виявилась на 6,2 відсотка нижчою за середню ринкову, бо контрактація перестала бути реакцією на дефіцит.
Що потрібно, щоб це працювало на реальних даних
- План виробництва кормів на горизонт закупівлі.
- Поточна контрактна позиція по кожній сировині.
- Джерело цін, яким ви користуєтесь.
- Ваша політика закупівель: скільки місяців уперед і які ліміти.
- Людина, яка ухвалює рішення про контрактацію.
Звідки агент бере дані і що робить, коли їх немає
Три варіанти старту, вимоги до даних і поведінка при збоях
Стосується всіх 13 агентів
Що показує цей сценарій
Відповідає на три питання, які ставлять першими: де старт роботи агента, які вимоги до чистоти даних і які інтеграції потрібні. Коротка відповідь: почати можна з вивантажень, ідеальний облік не потрібен, а от сім полів потрібні.
- Читання і запис розділені жорстко
- Розклад видно, тобто зрозуміло, наскільки свіжі дані
- Поведінка при недоступності описана заздалегідь, а не вигадується під час збою

- Обовʼязкові поля це ті, без яких розрахунок неможливий у принципі
- Бажані поля підвищують точність, але їх відсутність не зупиняє агента
- Прогалина показується явно, а не заповнюється правдоподібним значенням

- Перший варіант не вимагає нічого від ІТ, крім файлів
- Другий вмикається після того, як агент довів, що рахує правильно
- Третій це окреме рішення після пілота, і воно не обовʼязкове

- Немає даних це стан, а не нуль
- Розрахунок, який спирався на відсутні дані, не показується як готовий
- Людина бачить, чого саме бракує і де це взяти

- Кожен запит до джерела з часом і результатом
- Кожна дія агента і кожне підтвердження людини
- Записи не редагуються і зберігаються разом з партією або документом

Підсумок
Пілот запускається на вивантаженнях за два тижні без жодної інтеграції. Читання з систем підключається після того, як агент довів, що рахує правильно. Права на запис не запитуються взагалі в межах першого етапу.
Що потрібно, щоб це працювало на реальних даних
- Один контакт з боку ІТ, який знає, де що лежить.
- Тестовий контур або копія даних, якщо працюємо з системами.
- Приклади вивантажень за два тижні для першого прогону.
Де агент діє сам, де питає людину і що буде при помилці
Головне заперечення і пряма відповідь на нього
Стосується всіх 13 агентів
Що показує цей сценарій
Знімає головне заперечення: що буде, якщо агент помилиться. Відповідь складається з трьох частин: що він взагалі не може робити, які пороги діють і як влаштоване навчання.
- Це фіксується в описі рішення і в договорі
- Це не змінюється налаштуванням
- Цей список складаєте ви, ми лише пропонуємо базовий

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

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

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

- Одна роль на один тип рішення, без «узгодити з усіма»
- Час на підтвердження невеликий, але він має бути виділений
- Якщо людина не відповідає, агент ескалує за правилом, а не мовчить

- Перемикач у вашому кабінеті, не в нас
- Діє одразу, без перезапуску
- Повернення на автопілот теж ваше рішення

Підсумок
Межі зафіксовані в описі рішення до початку робіт, а не обговорюються під час інциденту. За півроку роботи не було жодної дії агента поза межами, бо частина дій просто недоступна конструктивно.
Що потрібно, щоб це працювало на реальних даних
- Ваш список того, що агент не має робити ніколи.
- Пороги: при якому відхиленні агент діє сам, а при якому питає.
- Перелік людей, які підтверджують кожен тип рішення.
- Період премодерації: скільки тижнів кожне рішення проходить через людину.
Як ми перевіряємо агента до того, як він торкнеться ваших процесів
Прогони на ваших архівах, а не на синтетиці
Стосується всіх 13 агентів
Що показує цей сценарій
Відповідає на питання «як ви переконаєтесь, що він не помиляється». Головна ідея: агент проганяється на ваших архівних даних, де правильна відповідь уже відома, і кожна розбіжність розбирається.
- Кейси беруться з вашого архіву за минулий сезон
- Правильна відповідь відома заздалегідь, тому є з чим порівнювати
- Прогін повторюється після кожної зміни в розрахунку

- Кожна розбіжність розбирається з вашим фахівцем
- Частина знахідок це помилки в історичних даних
- Після кожного розбору прогін повторюється повністю

- Критерій погоджується до початку робіт
- Він вимірюваний і перевіряється тими самими прогонами
- Якщо критерій не досягнутий, це видно однозначно

- Беруться випадки, на які торік уже витратили час
- Порівнюється не тільки відповідь, а і хід міркувань
- Результат розбору стає правилом, а не разовим виправленням

- Результат пілота вимірюється критеріями, погодженими на старті
- Розширення йде за агентами, а не одразу по всьому
- Зупинка після пілота це теж передбачений варіант

Підсумок
До виходу на робочі дані агент проходить чотири набори перевірок на архіві за минулий сезон. Кожна розбіжність розбирається з вашим фахівцем, і половина з них виявляється помилкою не агента, а історичних даних.
Що потрібно, щоб це працювало на реальних даних
- Архів за минулий сезон: приймання, лабораторія, документи, рецептури.
- Кілька відомих спірних випадків, де ви знаєте правильну відповідь.
- Фахівець з вашого боку на розбір розбіжностей, кілька годин на тиждень.
- Погоджений критерій приймання: за яких цифр пілот вважається успішним.
Ваші обсяги: скільки роботи в цих процесах саме у вас
Живий калькулятор під ваші цифри
Стосується всіх 13 агентів
Що показує цей сценарій
Дає підставу для розмови про масштаб. Посуньте повзунки під свої цифри і побачите, скільки годин ручної роботи і скільки грошей у цих процесах саме у вас.
- Кожен показник рахується простою формулою, яку видно
- Хвилини на операцію взяті з типових вагових журналів, а не вигадані
- Ефект least-cost порахований за різницею з сценарію 12

- Оформлення ТТН зменшується до підтвердження вагаря
- Черга скорочується приблизно на 80 відсотків, а не зникає
- Підготовка документів залишається, але стає перевіркою, а не набором

- Вартість рахується за заповненим брифом
- До неї йде опис рішення з критеріями приймання
- Комерційна частина обговорюється окремо від демонстрації

- Питання закривають обсяги, доступ до даних, формат виходу і контур
- Відповіді в основному вибираються з готових варіантів
- Після брифу ви отримуєте опис рішення без зустрічних питань

Підсумок
Розмова про масштаб проєкту починається з ваших цифр, а не з наших припущень. Вартість рахується за брифом, бо вона залежить від кількості елеваторів і заводів, а не від кількості слайдів.
Що потрібно, щоб це працювало на реальних даних
- Ваші фактичні обсяги: машини, тонни, партії, рецептури.
- Заповнений бриф по тих агентах, які цікавлять першими.
Що потрібно від вас: готовий список для ІТ і для елеватора
Можна переслати одним повідомленням, нічого дописувати не треба
Стосується всіх 13 агентів
Що показує цей сценарій
Дає готовий перелік, який можна переслати своєму ІТ і завідувачу елеватора без переписування. Кожен пункт має відповідь на питання «навіщо» і «що буде без цього».
- Усе на читання, нічого на запис
- Формат файлів будь-який, який у вас уже є
- Два тижні даних достатньо для першого прогону

- Найбільше часу треба в перші два тижні премодерації
- Далі навантаження падає в кілька разів
- Якщо людини немає, це краще знати до старту, а не після

- Опис рішення не містить зустрічних питань, усе береться з брифу
- Критерії приймання фіксуються в описі, а не за фактом
- Оцінка дається діапазоном і окремо від документа

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

Підсумок
Підготовка до пілоту займає близько тижня замість місяця, бо перелік зрозумілий і повний з першого разу.
Що потрібно, щоб це працювало на реальних даних
- Один контакт з ІТ і один контакт з боку процесу.
- Рішення про зріз пілоту: який елеватор і який завод.
Безпека і контур: що виходить назовні, а що ні
Ціни контрактів, рецептури і умови з покупцями це чутливі дані
Стосується всіх 13 агентів
Що показує цей сценарій
Знімає питання служби безпеки до того, як воно стане блокером. Основна ідея: усе, що є комерційною таємницею, може взагалі не виходити за ваш контур, і це технічне рішення, а не обіцянка.
- Перший варіант найшвидший, третій найзакритіший
- Вибір режиму це ваше рішення, а не наше
- Режим фіксується в договорі, а не обговорюється в процесі

- Перелік полів фіксується і перевіряється вашим ІТ
- Ціни і умови контрактів у модель не передаються
- Розрахунок від моделі не залежить, вона тільки розбирає текст

- Записи не редагуються і мають час
- Видно, хто підтвердив кожну дію
- Строк зберігання за вашими вимогами

- Режим розгортання і перелік даних
- Права в системах і те, чого агент не робить ніколи
- Строки зберігання і порядок видалення даних

Підсумок
Режим погоджується зі службою безпеки до початку робіт. У варіанті з розгортанням у вашому контурі назовні не виходить нічого, включно з обчисленнями мовної моделі.
Що потрібно, щоб це працювало на реальних даних
- Позиція вашої служби безпеки щодо розгортання і щодо мовних моделей.
- Перелік даних, які не можуть залишати контур за жодних умов.
- Вимоги до журналювання і до строку зберігання записів.