Коротко: критерій відбору тут один — скільки годин щомісяця йде на збирання даних, а не на рішення. За цим критерієм із десятків можливих сценаріїв лишаються п'ять, і вони майже однакові в компаніях різного розміру.
1. Коментар до закриття місяця
Що зараз: звіт формується автоматично, а пояснювальну частину хтось пише руками, кожного місяця, дивлячись у ті самі цифри.
Що змінюється: асистент формує чернетку коментаря з проводок — що змінилося, на скільки, за рахунок чого. Людина перевіряє й дописує те, чого в даних немає.
Умова: план рахунків і категорії ГК не змінювалися посеред періоду, або зміни відомі. Про сам процес — у матеріалі про закриття періоду.
2. Дебіторка за поведінкою, а не за кошиками
Що зараз: звіт про старіння показує кошики. Хто з них справжня проблема, вирішується по пам'яті або не вирішується.
Що змінюється: перелік сортується за відхиленням від звичної поведінки клієнта, а не за днями прострочення. Клієнт, який завжди платить на 45-й день, не потрапляє в топ, а той, хто вперше затримав, — потрапляє.
Умова: заповнені умови оплати й застосовані до документів платежі. Детально — у розборі AI для дебіторки.
3. Розклад маржі
Що зараз: видно, що маржа впала. Чому — з'ясовується вивантаженням у Excel, і не щомісяця.
Що змінюється: розклад на складові за хвилини: закупівельні ціни, знижки понад політику, зсув міксу. З можливістю одразу запитати, у якій території чи в якого менеджера зосереджений ефект.
Умова, і вона тут найсуворіша: визначення маржі має бути узгоджене письмово. У Business Central їх щонайменше три залежно від того, яка собівартість береться. Без цього цифри розійдуться з вашим звітом.
4. Прогноз грошового потоку на фактах
Що зараз: прогноз будується за договірними термінами, тобто за тим, коли клієнти мали б заплатити.
Що змінюється: прогноз спирається на фактичну поведінку. Клієнт із термінами «14 днів», який стабільно платить на 35-й, стоїть у прогнозі на 35-му.
Умова: зобов'язання поза Business Central — зарплата, податки, кредити — треба додати свідомо, інакше прогноз буде впевнено оптимістичним. Суміжна тема — касовий розрив при зростанні.
5. Разові запитання власника
Що зараз: запитання приходить у четвер, відповідь готується до понеділка, і за цей час встигає застаріти.
Що змінюється: запитання ставиться прямо, відповідь приходить із посиланням на записи, які можна перевірити.
Умова: це найцінніший сценарій і водночас той, що найбільше залежить від стану налаштувань, бо запитання наперед невідомі. Якщо виміри заповнюються непослідовно, частина відповідей буде правдоподібно неправильною.
З чого почати
Порядок зазвичай такий: сценарії 2 і 1 — найпростіші й найшвидші, бо вузькі й добре визначені. Сценарій 3 — найцінніший, але вимагає роботи з визначеннями. Сценарій 5 — найбільш вражаючий і найризикованіший для першого запуску: широкий обсяг і жодних меж очікувань.
Практична рекомендація — починати з другого. Він дає видимий результат за два-три тижні, і на ньому стає зрозуміло, наскільки ваші дані готові до решти. Що з цього виходить у вигляді рішення — на сторінці AI для фінансів.
Часті запитання
Скільки часу це реально звільняє?
Залежить від того, скільки часу зараз іде на збирання. Чесна відповідь: порахуйте самі — скільки годин на місяць ваша команда витрачає на вивантаження й зведення перед тим, як почати аналізувати. Ця цифра і є верхньою межею ефекту, і вона в кожній компанії своя.
Чи потрібно змінювати процеси під це?
Самі процеси — ні. Але доведеться письмово зафіксувати визначення, які зараз існують у головах: що таке маржа, що входить у виручку, коли клієнт вважається активним. Це корисно саме по собі, незалежно від AI.
Чи можна почати з одного сценарію?
Не просто можна — так і треба. Спроба закрити все одразу подовжує проєкт і розмиває критерій успіху. Один вузький сценарій за два-три тижні показує, наскільки ваші дані готові до решти.
Що робити, якщо дані в поганому стані?
Спершу впорядкувати їх. Виміри, облікові групи, застосування платежів — це фундамент і для AI, і для звичайної звітності. Discovery цілком може закінчитися саме таким висновком, і це дешевший результат, ніж проєкт поверх безладу.
Хто в команді має цим займатися?
З боку фінансів потрібна людина, яка може узгодити визначення розрахунків — зазвичай головний бухгалтер або фінансовий контролер. Це кілька зустрічей, а не постійна зайнятість, але без цієї ролі проєкт буксує.