Придивіться до рахунку INV-88180. Три його позиції в сумі дають 8 240,00 $. А внизу надруковано підсумок: 8 420,00 $. Дві цифри помінялися місцями, і різниця становить 180 $.
Завантажений роботою працівник, який перевіряє рахунки, може й не помітити помилки. Автоматизований процес, який довіряє всьому, що витягнув, пропускатиме її щоразу — і передаватиме хибну суму далі як правильну.
Наше нове відео Checked, not trusted простежує шлях саме цього рахунку через DocReveal: від моменту, коли його читають, через перевірку, яка позначає його як проблемний, і до моменту, коли людина вирішує, що буде далі. Ролик триває три з половиною хвилини, переглянути його можна вгорі цієї сторінки, і створено його не для розробників, а для тих, хто несе відповідальність: фінансових директорів, відділів розрахунків із постачальниками, операційних підрозділів і аудиторів. Ось що ви побачите і чому це важливо.
Прочитати — не означає повірити
ШІ навчився дуже добре читати документи. Він безпомилково витягне кожен рядок рахунку INV-88180 — включно з хибним підсумком, адже надруковано саме його. Бездоганна копія документа з помилкою — все одно результат із помилкою.
Саме цю прогалину не закриває більшість рішень для автоматизації документів. Обробка прискорюється — а разом із нею зростає й швидкість, з якою помилки потрапляють до обліку, звітів і платежів. Вихід не в тому, щоб пригальмувати, а в тому, щоб автоматично перевіряти кожен документ на відповідність правилам, за якими вже працює ваш бізнес, — ще до того, як хтось покладеться на ці дані.
Читання: кожен рахунок стає даними
Відео починається в Reveal Manager, де шість вересневих рахунків обробляються за один запуск. Кожен файл розпізнається, зіставляється з моделлю рахунку, перевіряється за правилами й готується для аналітики, а дошка показує, на якому етапі перебуває кожен файл, поки триває запуск. Жодних шаблонів, які довелося б підтримувати: постачальники використовують різні макети й мови, а рахунки читаються такими, якими надходять.
П’ять рахунків проходять перевірку. Один, від постачальника під назвою Stavlund, — ні: перевірки за правилами для нього не пройдено.
Перевірка: правила, які написали б ваші аудитори
Перевірку, через яку рахунок не пройшов, налаштовано в Rules Manager. Там бізнес-користувач складає правила, клацаючи на поля, умови та значення: жодного коду, жодних скриптів. У відео одне правило вимагає, щоб сума позицій збігалася з підсумком рахунку. Інше стежить за тим, щоб той самий номер рахунку ніколи не траплявся у двох документах.
Ці перевірки детерміновані. Вони не питають у ШІ його думки: вони рахують і порівнюють — щоразу однаково. Правила групуються, версіонуються й публікуються свідомо, а журнал аудиту показує, хто створив, змінив і опублікував кожну версію. Коли через кілька місяців хтось запитає, чому рахунок позначили як проблемний, відповідь уже буде зафіксована.
Результат — вердикт з обґрунтуванням. У Business Rules Validation рахунок INV-88180 позначено як такий, що не пройшов перевірку, — із зазначенням конкретного порушеного правила й значень, які за ним стоять: позиції на суму 8 240,00 $ проти надрукованого підсумку 8 420,00 $. Не «щось не так», а що саме, де і на скільки.
Негативний вердикт — не глухий кут. Він зберігається разом із документом і публікується як подія, тож може запустити потік в Integration Manager або розбудити ШІ-агента, який зробить наступний крок.
Рішення: агент, який знає, коли запитати
У другій половині відео ця подія будить ШІ-агента для сортування рахунків — він працює в Agent Manager і є одним із цифрових колег, про яких ми розповідали в статті Agent Pool. Ніхто не запускає його вручну: він спрацьовує сам щоразу, коли завершується перевірка документа. Його перший крок — не діяти, а прочитати: вердикт за правилами та витягнуті дані рахунку.
Агент працює в межах, які встановив його власник: визначений набір інструментів, максимальна кількість кроків за один запуск і профіль автономності, що вирішує, які дії потребують схвалення людини. Його інструкції однозначні щодо рахунків, які не пройшли перевірку: їх передають людині. Тож агент робить те, що зробив би хороший колега: запитує. Запуск стає на паузу в скриньці погоджень, де викладено запитання й можливі відповіді.
Людина читає запитання й вирішує притримати рахунок і запросити виправлений. Агент відновлює роботу, занотовує рішення й завершує її. Журнал запуску показує кожен крок: що агент прочитав, про що запитав, яку відповідь отримав і чим завершився запуск. Скринька знову порожня, і не сталося нічого, чого не можна було б пояснити.
Чому це важливо не лише для одного рахунку
INV-88180 — маленька історія про 180 $. Але принцип, що за нею стоїть, стосується кожного документа, який обробляє ваша компанія, і вміщається в один рядок: ШІ пропонує. Правила перевіряють. Люди вирішують.
- Сприймайте витягнуті дані як пропозицію, а не як факт. Знайдіть місця, де витягнуті дані використовують без жодної перевірки, — саме там місце вашим першим правилам.
- Запишіть перевірки, які ваші працівники й так роблять за звичкою. Підсумки, що мають сходитися, номери, що мають бути унікальними, значення, що мають залишатися в допустимих межах. Якщо це перевіряє людина, правило може перевіряти це в кожному документі.
- Дайте автоматизації змогу зупинитися й запитати. Агент, який передає іншим те, що вирішувати не йому, цінніший за того, який вирішує все.
- Зберігайте записи. Версіоновані правила, вердикти з обґрунтуванням і журнали запусків агентів із відповідями людей перетворюють «так зробила система» на історію, придатну для аудиту.
Усі компанії та цифри у відео — вигадані демонстраційні дані.
Перевірено, а не взято на віру. Кожен документ. Саме так автоматизація заслуговує на довіру.