Чому AI-фінансовий аналітик видає прогнози, яким не вірять
Типова картина: AI-фінансовий аналітик навчений на вивантаженні, яке збирали «під звіт», а не під прогноз. Виручка в обліковій системі рознесена за документами, у плані — за договорами, у комерції — за угодами у воронці продажів.
Модель усереднює все це й видає прогноз виручки, який розходиться з фактом на десятки відсотків уже до кінця першого місяця.
Корінь — у якості облікових даних. Дублі контрагентів, сторнуючі проводки, закриття періоду із затримкою на тижні, ручні правки в 1С і таблицях фінансиста не проходять жодної перевірки на вході. Кожен такий розрив модель завчає як закономірність і потім відтворює її в прогнозі.
Далі працює накопичення: розходження плану й факту пояснюють «разовими факторами», цифру правлять руками перед кожним захистом бюджету — і довіра до прогнозу падає до нуля.
Керівництво повертається до ручних зведень у таблицях, а фінансовий аналітик витрачає на збірку кілька днів на місяць замість розбору причин відхилень.
Це не слабкість моделі, а відсутність контуру даних навколо неї: зведення джерел, правила звірки, контроль якості на вході та зрозуміла процедура пояснення розходжень. Розбираємо, як це закривається — від єдиного шару облікових даних до перевірки прогнозу на історичних періодах.
Вимірювані ефекти: швидкість, точність, зняті ризики
Ефект вимірюємо до запуску: на історичних даних проганяємо ті самі зведення й прогнози, які сьогодні збираються вручну, і порівнюємо метрики один в один. Що саме фіксуємо в прийманні:
- Термін підготовки звітності. Управлінське зведення перестає збиратися 2–3 дні: нічний перерахунок забирає дані з облікових систем (включно з 1С) і сховища, звіряє та рахує відхилення — до ранку вітрина готова за центрами відповідальності.
- Точність прогнозу. Модель перевіряємо на закритих періодах: за ключовими статтями помилка на горизонті 3–6 місяців нижча, ніж у планування на таблицях, причому не на словах, а на відкладеній вибірці.
- Раннє виявлення відхилень. Пороги за статтями та коефіцієнтами задаємо разом із фінансистами — 80–90% виходів за поріг спливають до закриття періоду, а не в момент підписання звіту.
- Касовий розрив. Платіжний календар будується на 4–8 тижнів уперед у кількох сценаріях: загроза розриву видна за 2–3 тижні, коли її ще закривають перемовинами з постачальником або зсувом платежу.
- Контроль витрат і знятий клас відмов. Проводки розмічаються автоматично за статтями та договорами, частка операцій без ручного рознесення виходить на 90%+. Зникає й розходження «цифра у звіті не сходиться з джерелом»: єдина вітрина та журнал розрахунків розмотують будь-яку суму до проводки.
Метрики записуємо в критерії приймання до старту робіт — не зійшлося, робота не прийнята.
Способи впровадження: готова модель, своя, гібрид
Режим впровадження обирають не за «рівнем технологічності», а за зрілістю даних: скільки є розмічених прикладів розбору фінансової звітності, хто відповідає за розмітку й наскільки суворі вимоги до ізоляції. Від цього залежить, де проходить межа між готовою моделлю та вашою предметною логікою.
| Варіант | Коли підходить | Обмеження підходу |
|---|---|---|
| Готова модель за підпискою | Швидкий старт, типові форми звітності, мало історичних прикладів | Не знає вашу номенклатуру статей, довідники та правила консолідації; доналаштування сценаріїв обмежене налаштуваннями постачальника |
| Дообучення на своїх даних | Є 3-5 закритих періодів із вивіреними проводками та відповідальним за розмітку | Потребує регламенту версіонування датасету: без нього модель деградує при зміні облікової політики |
| Гібридна схема | Звітність нестандартна, але частина операцій типова | Складніша підтримка — потрібен шар маршрутизації запитів і контроль розходження відповідей між контурами |
Різниця проявляється на етапі розрахунку коефіцієнтів і звірки відхилень: готова модель відповідає за загальною логікою, дообучена — за вашою методикою. Гібрид закриває обидва випадки, але потребує явного правила, який запит куди йде.
Перехід між варіантами залишаємо відкритим: конфігурація та довідники переносяться, тому почати можна з готової моделі й пізніше дообучити її на накопичених розборах.
Як ми впроваджуємо: від аудиту даних до передачі
Впровадження аналітика — це не встановлення готового продукту, а ланцюжок інженерних кроків, де кожен наступний спирається на результат попереднього. Ми не починаємо рахувати метрики, поки не розуміємо, звідки беруться дані й наскільки їм можна довіряти.
- Аудит даних. Збираємо перелік джерел: вивантаження з облікових систем, таблиці ручного введення, зовнішні файли. Перевіряємо періодичність оновлення, дублі, пропуски та розходження між системами — на виході карта джерел з оцінкою придатності для розрахунку.
- Схема метрик. Узгоджуємо визначення: що вважаємо виручкою, як трактуємо відтік, які періоди порівнюємо. Формули та правила перерахунку фіксуємо письмово — інакше розходження між аналітикою й обліком спливає на розборі звітів, а не в розрахунку.
- Налаштування розрахунків. Реалізуємо звірку, агрегацію за періодами, рознесення за підрозділами та контрагентами. Ключова властивість результату — відтворюваність: один і той самий вхід завжди дає одну й ту саму цифру, а кожне значення розкривається до вихідної проводки.
- Перевірка на історії. Проганяємо розрахунок на вже закритих періодах і звіряємо з фактичними звітами. На цьому кроці зазвичай і розкриваються помилки у вихідних даних: частка рядків, де цифри не сходяться, показує реальну якість обліку до початку робіт.
- Дослідна експлуатація. Аналітик працює паралельно зі звичним процесом, ми дивимося, де він помиляється й наскільки зрозумілі пояснення до цифр. Правимо формулювання, пороги відхилень і правила перерахунку за фактичними питаннями фінансистів.
- Передача рішення. Віддаємо доступи, регламент оновлення даних, інструкції та розбір типових ситуацій. Навчаємо команду, яка буде працювати з аналітиком щодня, — після цього рішення живе й розвивається без нашої участі.
Що залишається в команди замовника після проєкту
Проєкт закривається не тоді, коли аналітик видав перший звіт, а коли ваша команда може змінити логіку розрахунку, додати джерело даних або відкликати доступ без нас. Тому передаємо не «працюючий сервіс», а набір артефактів, за якими рішення живе всередині компанії.
- Документація рішення — шари: приймання даних, нормалізація, розрахунковий контур, пояснення результатів; схема потоків і точки підключення нового джерела.
- Довідник метрик — за кожною величиною формула, джерело, період агрегації, власник і поведінка при пропусках; за ним звіряємо показники з обліковою системою.
- Налаштовані розрахунки — правила зіставлення статей, сценарії перерахунку, пороги аномалій винесені в конфігурацію: правку робить аналітик, а не розробник.
- Правила доступу — ролі на первинні дані, агрегати та вивантаження, журнал звернень до чутливих полів, порядок відкликання при зміні співробітника.
- Регламент оновлення — як додати метрику або джерело, як перевірити якість даних до публікації та як відкотити невдалу зміну розрахунку.
- Інструкція з супроводу власними силами — типові операції: перерахунок періоду, розбір розходження, реакція на скаргу до показника.
Середовища, доступи та розклад завдань переводимо на ваші облікові записи, щоб рішення залишалося працездатним без нашої участі. Знадобиться розширення контуру — повернемося з оцінкою та планом.
Кейс: прогноз за філіями перестав розходитися з фактом
Мережа з 38 філій, зведення за кожною — виручка, собівартість, відхилення від плану — збиралося вручну: фінансисти вивантажували таблиці з облікових систем, зводили їх в один файл і правили розходження «на око».
Підготовка займала два робочих дні, і на момент, коли зведення потрапляло до керівництва, частина цифр встигала застаріти.
Що знайшли при розборі
Виявилося, що розходження прогнозу з фактом — не проблема моделі, а проблема входу: у філіях по-різному класифікували одні й ті самі витрати, дублювалися довідники контрагентів, а частина коригувань жила лише в особистих файлах.
Через це прогноз не сходився з фактом за 4 філіями з 10, а частка точних прогнозів трималася близько 62% — і це вважалося нормою.
Що змінили
Звели дані філій в єдину вітрину на ClickHouse, зафіксували довідники та правила класифікації, додали перевірки якості на вході: неповний період або нетиповий стрибок витрат зупиняють розрахунок, а не йдуть у звіт.
Прогноз перераховується за розкладом, версія розрахунку зберігається — видно, на яких даних він побудований і що змінилося після правок.
Що стало
Зведення готується за 20 хвилин замість двох днів і оновлюється без ручних вивантажень. Частка точних прогнозів зросла з 62% до 91%, розходження з фактом залишилося за однією філією з десяти — і за нею одразу видно причину: пізня передача даних. Фінансова служба переключилася з перезбирання таблиць на розбір відхилень.
Чим відрізняється цифровий аналітик від звітів в обліковій системі
Звітність в обліковій системі відповідає на питання «що вже сталося»: регістри сходяться, проводки на місці, сальдо закрито.
Але розріз даних у ній заданий структурою рахунків і довідників заздалегідь — на питання «чому маржа просіла саме в цьому напрямку» вона дає цифру без пояснення.
Цифровий аналітик будується поверх того самого контуру, але працює з аналізом причин відхилень. Він зіставляє план і факт порядково, розкладає розходження на фактори — обсяг, ціну, курс, структуру витрат — і показує, яка частка відхилення припадає на кожен із них.
Далі вмикається сценарний розрахунок: аналітик приймає набір припущень — зсув попиту, зростання закупівельних цін, курсова динаміка — і перераховує модель, не вивантажуючи дані в таблиці вручну. Джерело тут те саме, що й в обліковій системі, тому розходжень між контурами не виникає.
Різниця підходів в одному: звіт фіксує результат, аналітик пояснює його й рахує варіанти розвитку подій. Кожне число в моделі простежується до проводки або документа-підстави, тому висновок можна захистити перед аудитом і керівництвом.
Є й обмеження: якщо в обліковій системі немає аналітичних ознак — центрів відповідальності, статей, проєктів, — цифровий аналітик не створить їх з повітря. Тоді робота починається з ревізії плану рахунків і довідників, і лише потім будується модель.
Технічні сумніви перед стартом: відповідаємо по суті
Сумніви перед стартом зазвичай одні й ті самі: чи вкладеться аналітик у реальні дані, чи доведеться перебудовувати облік, хто відповідає за збої. Розбираємо за пунктами — без обіцянок повної автономності, яких не дасть жодна команда.
Наскільки точні розрахунки на наших даних, якщо частина проводок неповна?
Точність перевіряємо не на демонстраційному наборі, а на вашому вивантаженні за закриті періоди: збираємо еталонну вибірку операцій і звіряємо за нею висновки аналітика за кожною категорією.
Там, де даних не вистачає — немає рознесення за контрагентами або є ручні коригування, — висновок позначається як неповний, а не добудовується здогадом.
Фінансовий облік у нас у кількох системах — це проблема?
Починаємо зіставлення довідників: контрагенти, статті та періоди приводяться до єдиного вигляду, а розходження в методології описуються правилами, а не віддаються на розсуд моделі. Нове джерело не переписує логіку — до неї додається правило зіставлення.
Чи можна запускати поетапно, не зупиняючи закриття періоду?
Так: аналітик рахує ті самі показники паралельно з поточним порядком, фінансова служба звіряє результати, і лише після сходження він входить у регламент. Починаємо з одного контуру — наприклад, виручка та каса, — потім підключаємо звітність і прогноз. Відкат на будь-якому етапі повертає попередній процес без втрати даних.
Які доступи потрібні до фінансових даних і де ваша зона відповідальності?
Доступ мінімально достатній: читання з облікових систем або вивантажень, як правило, у знеособленому вигляді — без персональних даних і платіжних реквізитів. Звернення логуються, схему узгоджуємо з вашою службою безпеки до початку робіт.
Ми відповідаємо за модель, правила зіставлення, відтворюваність розрахунку й документацію; за повноту первинного обліку — ваша сторона.
Обговоримо задачу та повернемося з оцінкою й планом робіт
Щоб оцінка проєкту спиралася на факти, а не на припущення, нам потрібні вихідні дані за вашим контуром. Опишіть задачу у вільній формі: що має робити AI-фінансовий аналітик, які рішення він підтримує й який результат ви вважаєте коректним. У відповідь повернемося з оцінкою, етапами та планом робіт.
Готувати щось спеціально не потрібно — беремо те, що вже є в роботі: вивантаження, регламенти, приклади звітності. Уточнювальні питання поставимо самі.
- Які джерела вже є — облікова система, банківські виписки, реєстри, таблиці — у якому вигляді та як часто оновлюються.
- Які звіти й розрахунки аналітик має видавати зараз і що в них заважає або займає найбільше часу.
- Знеособлений приклад даних за кілька періодів, щоб перевірити повноту й якість до старту.
- Як влаштований поточний процес: хто готує звітність, де найчастіше з'являються розходження та помилки.
- Вимоги до контуру: закритий сервер або зовнішні сервіси, правила доступу, зберігання та журналювання.
- Хто з боку замовника приймає результат і за якими критеріями вважає розрахунки вірними.
Цього достатньо, щоб оцінити трудомісткість, запропонувати порядок старту й зафіксувати склад етапів. Опишіть задачу — повернемося з оцінкою та планом робіт.
