Звіт готовий ще до того, як ви почнете переносити дані

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

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

О дев’ятій нарада. О восьмій досі бракує трьох файлів

Уявімо операційну команду, яка щотижня зводить звіти з кількох філій. Одна надсилає таблицю в PDF, друга — скан, третя — електронну таблицю. Працівник копіює значення, виправляє одиниці та намагається з’ясувати, чи документ охоплює весь тиждень, чи лише його частину.

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

Що зупиняє роботу?

Початкова ситуація

Концептуальне зображення, створене за допомогою ШІ
  1. Та сама назва, інше значення

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

  2. Пропуск, схожий на нуль

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

  3. Результат без шляху до джерела

    Щоб відповісти на запитання про окрему позицію, працівник переглядає папки й листування. Зведення не зберігає ні документа, ні місця, звідки взято значення.

Спочатку спільна мова даних, потім автоматизація

Починаємо з визначення звіту: періоду, одиниць, обов’язкових джерел і способу обчислення кожної позиції. Лише після цього обираємо зчитування таблиць, OCR або модель ШІ. Різні документи можуть потребувати різних методів.

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

Так може виглядати новий процес

Ілюстрація процесу
  1. Зберіть і розпізнайте документи

    Файли надходять через погоджений канал: папку, форму або інтеграцію. Система визначає відправника, період і тип документа та виявляє повторне надходження того самого файла.

  2. Прочитайте значення в єдиному форматі

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

  3. Зупиніть дані, що потребують уваги

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

  4. Погодьте й опублікуйте версію

    Уповноважена людина перевіряє повноту підсумку. Виправлення джерела створює нову версію звіту із зазначенням змін замість непомітного редагування вже погодженого результату.

ШІ допомагає читати. Правила зберігають зміст

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

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

Хто може бачити первинний документ?

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

Почнімо з одного фрагмента, який працює.

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

Як зрозуміємо, що стало краще?

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

  • Час роботи над звітом

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

  • Ефективність перевірок

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

  • Можливість пояснити результат

    Перевіряємо, чи може користувач перейти від позиції у зведенні до джерела та відтворити причину відмінності між двома версіями звіту.

Запитання, які варто поставити

Чи можна зчитувати також скани?

Так, за допомогою OCR, але якість скану впливає на результат. Перевіряємо приклади з реального обігу: нахилені сторінки, печатки, слабкий контраст і рукописні примітки. Для нечитабельних документів потрібен порядок виправлення або ручної перевірки.

Що буде, якщо постачальник змінить структуру звіту?

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

Подивіться на це в щоденній роботі.

Приклади сценаріїв. Конкретні процеси, рішення та можливі способи реалізації.

Який звіт забирає у вас цілий ранок?

Підготуйте знеособлені приклади документів і потрібного зведення. Цього достатньо, щоб почати розмову про доцільний обсяг автоматизації.

Обговорімо проєкт