Спитайте фінансову команду, куди йде час на рахунки, і «на набір тексту» відповідають рідко. Іде на цикл: відкрити лист, розібратися, до якої юрособи і центру витрат це належить, звірити суму із замовленням, наздогнати погоджувача, помітити, що це дубль оплаченого минулого тижня, — і лише потім увести.
Автоматизація, яка робить лише витягання, атакує найменшу частину цього циклу. Добре окупаються ті проєкти, що роблять ще й зіставлення, перевірку на дублі, валідацію за політикою та проведення, бо саме там живуть і хвилини, і помилки.
Візьмемо фінансову функцію середнього розміру: 800 рахунків на місяць, у середньому дев’ять хвилин на кожен, повна вартість години 35 €. Це 120 годин на місяць, приблизно 4 200 €, або близько 50 000 € на рік ручної обробки.
Реалістична автоматизація проводить напряму близько 70% — часто більше, іноді менше, і де провести межу між «саме» і «на перевірку», на практиці вирішує клієнт, — решту скеровує людині, і та тепер витрачає чотири хвилини на виняток замість дев’яти хвилин на все. Ручне навантаження падає приблизно до 25–30 годин на місяць. Економія — в районі 35 000 € на рік проти впровадження, що коштує частку від цього; тому це найчастіший перший проєкт, який ми бачимо у фінансах.
Зверніть увагу, чого модель не припускає: вона не припускає 100% автоматизації і не припускає, що винятки стануть безкоштовними. Будь-який розрахунок окупності, що припускає хоч одне з цього, — той, з яким потім сперечатимуться.
Точність витягання цитують у презентаціях; економію визначає частка прямого проведення. Система, що читає поля з точністю 99%, але все одно відправляє 60% рахунків людині на підтвердження, заощадила вам дуже мало.
Частка прямого проведення — здебільшого функція ваших правил, а не моделі. Рахунки, що збіглися із замовленням у межах допуску, від відомого постачальника, нижче порога погодження, без ознак дубля, можуть проводитися автоматично. Кожна з цих умов, яку ви не можете перевірити, — це категорія рахунків, що зобов’язана йти людині. Тому перше питання ми ставимо не про обсяги, а про те, чи існують замовлення на закупівлю і чи послідовно вони використовуються.
Чотири умови відділяють впровадження, які влучають у свої цифри, від тих, що шкутильгають.
Довідник постачальників, який справді підтримують. Зіставлення з постачальником — перший крок ланцюжка, і падає воно на дублях і застарілих записах, а не на поганому OCR.
Облікова система, яка приймає API або імпорт. Якщо проведення наприкінці все одно роблять руками, ви автоматизували просту половину.
Записані правила погодження. Хто що погоджує, на якому порозі і що ніколи не має проводитися автоматично. Якщо це не записано, воно й стає проєктом.
Хтось, хто володіє винятками. Ті приблизно 30%, що не проходять напряму, потребують столу. Автоматизація робить цей стіл меншим, а не непотрібним.
Нижче приблизно 300 рахунків на місяць арифметика зазвичай не працює, і добре зроблений шаблон плюс дисциплінований процес обіграють впровадження за вартістю. Якщо рахунки приходять переважно сканами паперу від постачальників, які нічого міняти не будуть, чекайте нижчої частки прямого проведення і плануйте стіл винятків до того, як щось підпишете.
А якщо справжня проблема в тому, що погодження повертаються три тижні, автоматизація прискорить усе, крім того, що реально повільне. Це проблема процесу, і ми так і скажемо, а не продаватимемо в обхід.
Повна сторінка: як працює потік, з чим інтегрується, ціна та обмеження.
Ваш обсяг, ваші хвилини, ваша ставка — термін окупності наприкінці.
Галузеві обмеження, всередині яких це доводиться будувати: чотири ока, аудиторський слід, резидентність.
Ми використовуємо cookie лише для аналітики — щоб бачити, з яких сторінок приходять заявки. Нічого більше й нічого до вашої згоди. Політика cookie