AI автоматизація видачі дозволів: де рветься процес
Регламентний строк розгляду заяви та фактичний розходяться вже на вході. Заява потрапляє до загальної черги необроблених звернень, де змішані первинні подання, продовження, переоформлення та запити на роз'яснення.
Фахівець бере їх у порядку надходження, а не за складністю, тому прості пакети чекають за складними, і заявник дізнається про статус лише після першого дотику.
Далі починається ручна перевірка комплектності документів — порядкове звіряння пакета з переліком з регламенту. Неправильна форма довідки, прострочена довіреність або відсутній додаток виявляються не на прийманні, а через кілька днів, коли фахівець дійшов до заяви. Звідси й береться основна частка повернень заяви на доопрацювання.
Повернення запускає зворотний відлік: строк розгляду заяв обнуляється, заявник усуває зауваження, подає повторно і знову стає в чергу. Частина заяв проходить це коло двічі — кожен цикл додає комплект документів у роботу і зсуває строки щодо інших.
Міжвідомчі запити рвуть процес удруге: відомості запитуються вручну, відповіді надходять у різних форматах і переносяться до облікової системи руками. Статус при цьому не змінюється, і пояснити затримку заявникові нема чим.
У підсумку пропускна здатність упирається не в регламент, а в обсяг рутини на одного фахівця. Розбираємо, як автоматизація видачі дозволів закриває кожне з цих місць — від приймання пакета до повідомлення про рішення.
Що змінюється після впровадження: ефекти в строках і відмовах
Первинний розбір заяви перестає бути вузьким місцем. Раніше фахівець приймання вручну звіряв комплектність, вичитував вкладені скани і вже на цьому кроці надсилав заяву на повернення, якщо чогось бракувало.
Тепер перевірка комплектності, форматів і обов'язкових полів іде до людини: на стіл надходить заява з розміченими даними та списком того, що підтверджено автоматично.
Частка повернень заяв — найдорожчий клас відмови: кожне повернення означає повторне подання, повторну перевірку і ще один цикл очікування для заявника.
Автоматична перевірка на поданні замінює відмову конкретним переліком відсутнього — комплект доповнюється до старту розгляду, а не за фактом відмови.
На практиці частка повернень скорочується в кілька разів, а прозорість маршруту погодження стає видимою: заявник бачить поточну стадію, наступного погоджувача і те, що від нього вимагається.
Навантаження на фахівців приймання зміщується з рутинного звіряння на розбір спірних випадків. Маршрут заявки описано явно — на Camunda збирається схема проходження з таймаутами й ескалаціями, тому порядок погодження виконується однаково незалежно від завантаження відділу.
Звідси й однаковість рішень: однотипні заяви проходять один і той самий набір перевірок, а розбіжності йдуть на розбір, а не розчиняються у статистиці.
Після запуску має сенс вимірювати чотири величини: час первинного розбору, частку повернень, частку заяв, закритих без ручного втручання, і середню кількість погоджувачів у маршруті.
Якщо строк розгляду скорочується, повернення падають, а частка автоматично закритих зростає — працює зв'язка правил і маршруту. Якщо зростання немає — проблема в правилах перевірки, а не в розпізнаванні.
Способи перевірки заяв: правила, моделі, гібридні схеми
Перевірка заяви розпадається на дві різні задачі. Перша — комплектність: наявність документів, строки дії, збіг відомостей з довідниками та реєстрами. Друга — оцінка ризику по суті: суперечності між документами, нетипові поєднання підстав, ознаки недостовірних відомостей.
Перша закривається правилами, друга — статистикою за минулими рішеннями, і від пропорції цих задач залежить вибір схеми.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила та довідники | Однотипний потік, вимоги повністю описані в регламенті | Не бачить смислових суперечностей усередині комплекту; кожен новий випадок — ручна правка правил |
| Модель на історичних рішеннях | Накопичено великий корпус рішень, частина підстав не формалізується текстом | Потребує розмічених даних; на рідкісних типах заяв помиляється і не пояснює відмову |
| Гібридна схема | Змішаний потік: формальна частина плюс оцінка ризику по суті | Дорожча в налаштуванні — потрібні і правила, і підготовлений корпус рішень |
Гібридна схема зазвичай дає найкращий баланс: правила не пропускають заяву далі без повного комплекту, а модель ранжує ризик і віддає спірні справи фахівцеві з поясненням, які пункти її насторожили.
Ключовий етап тут — підготовка історичних рішень: розмітка минулих справ за типами заяв і підставами відмови. Без неї модель успадковує різночитання попередніх перевірок, і точність на рідкісних випадках падає. Опишіть свій потік звернень — повернемося з оцінкою та планом.
Етапи впровадження: від розбору маршруту до передачі системи
Перш ніж писати код, ми проходимо маршрут заявника цілком — від подання до видачі документа — і фіксуємо кожне місце, де рішення ухвалює людина. Це дає карту погоджень, список зовнішніх джерел даних і розуміння, які перевірки формалізуються, а які залишаються за інспектором.
- Розбір маршруту послуги. Проходимо процес разом із співробітниками: форми, вкладення, журнал погоджень і відмов. На виході — карта етапів з точками втрати часу.
- Схема правил перевірки. Нормативні вимоги переводимо в однозначні умови: що перевіряється автоматично, що потребує документа, що залишається за людиною.
- Підготовка даних. Розбираємо історичні заявки, прибираємо дублі, приводимо довідники до єдиного вигляду — на реальних випадках правила перевіряються точніше.
- Інтеграція з відомчими реєстрами. Налаштовуємо обмін із зовнішніми джерелами й описуємо поведінку за їх недоступності: заявка не губиться, а стає в чергу на повторний запит.
- Пілотний запуск. Обмежений потік заявок іде паралельно зі звичайним порядком — розбіжності розбираємо за кожною заявкою і правимо правила.
- Замір метрик до і після. Рахуємо час розгляду, частку повернень і помилок у комплектності до пілота і після, показуємо різницю.
- Розширення та передача. Підключаємо решту типів заяв, навчаємо співробітників, передаємо документацію та доступи.
Етапи йдуть послідовно: розширення починається лише тоді, коли пілот підтвердив точність правил на реальному потоці.
Що залишається у вас: регламенти, схеми та реєстр правил
Систему можна передати в супровід лише разом з описом того, як вона ухвалює рішення. Тому до комплекту входять не лише сервіси та доступи, а й робоча модель процесу — за нею ваша команда зможе змінювати логіку погодження своїми силами.
- Реєстр правил перевірки — кожна умова видачі з джерелом (норма або внутрішній порядок), власником і датою останньої правки; нова редакція вноситься до реєстру, а не в код.
- Схема маршруту та ролей — які гілки проходить заявка, хто погоджує на кожному кроці, де повернення на доопрацювання і що система робить автоматично.
- Регламент розбору спірних випадків — критерії, за яких заявка йде до фахівця, строки розгляду та порядок фіксації рішення.
- Журнал рішень та аудит — за кожною заявкою видно, які правила спрацювали, на яких даних і хто зі співробітників втрутився; вивантаження готується для внутрішнього контролю.
- Інструкції для фахівців — приймання заявок, запуск і зупинка обробки, типові збої та відкат правил до попередньої редакції.
- Матриця відповідності — зіставлення пунктів нормативних документів і правил реєстру: у разі зміни вимог одразу зрозуміло, що саме правити.
- Порядок зміни правил — хто погоджує правку, як вона перевіряється на раніше оброблених заявках і як відкочується.
Комплект розрахований на те, що розвивати систему буде ваша команда: навчання проходить на ваших же заявках, а наш супровід закінчується там, де правки правил і маршрутів вносяться вже без нас.
Кейс: розбір потоку заяв за одним видом ліцензій
Йдеться про вид ліцензій з масовим потоком однотипних заяв: сотні звернень на місяць, фіксований перелік документів і ручна первинна перевірка кожного пакета.
Строк первинної перевірки сягав п'яти робочих днів, а в пікові тижні черга розтягувалася до трьох тижнів — заявник дізнавався про формальну помилку вже після початку розгляду.
Розбір потоку показав, що причини відмов передбачувані: неповний комплект додатків, розбіжність відомостей у заяві та в доданих сканах, прострочена довіреність представника.
Ці перевірки формалізуються, тому ми винесли їх в автоматичний шар: модель розбирає пакет документів, звіряє поля з даними Реестр лицензий і віддає інспекторові картку з підсвіченими розбіжностями замість стосу сканів.
Що змінилося в цифрах
Строк первинної перевірки скоротився з п'яти робочих днів до чотирьох годин для 78% заяв — решта йде в ручний розбір через нечитабельні скани або нестандартні додатки. Частка рішень з ручним розбором упала зі 100% до 19%, а повернення на доопрацювання — з 34% до 8%.
Час, що вивільнився, інспектори витрачають на змістовні питання — оцінку відповідності вимогам, а не на перегортання сторінок.
Кожен автоматичний висновок зберігає посилання на пункт правил і фрагмент документа, за яким його ухвалено, тому спірні випадки розбираються без відновлення логіки заднім числом.
Що робити, якщо частину перевірок уже виконує система
Першим кроком ми розбираємо те, що вже працює: які перевірки виконує система, де живуть правила — у формах, скриптах, довідниках чи регламенті для співробітника, — і на яких даних ухвалюється рішення.
Інвентаризація дає карту процесу: видно, які кроки закриті автоматикою, де обов'язкова людина і які відомості надходять із зовнішніх джерел. Без неї будь-яка доробка ризикує продублювати перевірку або тихо вимкнути чинне обмеження.
Далі чинні правила перевикористовуються, а не переписуються. Наявні перевірки залишаються джерелом істини й підключаються до нового шару як є, а поруч ставляться ті, яких бракує: звіряння із зовнішніми реєстрами, розрахунок ризику, контроль комплектності. Частково автоматизований процес не ламається — він розширюється.
Приймання заявок при цьому не зупиняється. Нова логіка запускається в тіньовому режимі й рахує рішення паралельно з поточною, не впливаючи на видачу; на потоці реальних заяв видно, де результати збігаються, а де розходяться.
Розбіжності розбираємо за причинами: застаріле правило, неповні дані, різне тлумачення норми. Журнал рішень показує частку збігів і повторювані спірні випадки — за ними правило уточнюється або скасовується усвідомлено, а не за фактом скарги.
Перемикання робимо поетапно, за типами послуг і видами заяв, а не одним днем. Старий ланцюжок залишається робочим і слугує точкою відкату, тому повернення до попереднього порядку можливе без втрати вже прийнятих заяв.
Обмеження та ризики: дані, відповідальність, спірні випадки
На вхід система отримує заяви в різному вигляді: електронні форми, скани, паперові звернення, вивантаження із суміжних систем.
До старту розробки ми фіксуємо, які поля заповнюються автоматично, які підтверджує фахівець, а які йдуть на ручний розбір, — від цього залежать і набір перевірок, і вимоги до журналу рішень.
Спірні заяви — не збій, а частина роботи відомства: заявник оспорює відмову, норма тлумачиться двояко, документи неповні. Тому пояснюваність рішення і можливість відкату закладаються в проєкт одразу, а не прикручуються після запуску.
Що робити, якщо вихідні дані різної якості?
Паперові заяви розпізнаються, але поля з низькою впевненістю в автоматичну обробку не йдуть: їх позначають, і вони потрапляють до фахівця. Частка помилок не зростає разом з обсягом потоку, а якість даних стає вимірюваною — видно, які типи заяв потребують доопрацювання форми.
Модель упереджена?
Перевіряємо, як рішення розподіляються за категоріями заявників і типами об'єктів. Якщо відхилення концентруються без нормативної підстави, це дефект правил або навчальних прикладів: переформульовуємо правило, а не «підкручуємо» поріг чутливості.
Хто відповідає за виданий дозвіл?
Система готує проєкт рішення з посиланнями на норми та переліком виконаних перевірок, підпис і відповідальність залишаються за посадовою особою. Кожна дія і кожна правка фіксуються в журналі, тому розбір звернення і перевірка ззовні займають хвилини, а не дні.
Обговоримо задачу і повернемося з оцінкою та планом робіт
Оцінка обсягу робіт з автоматизації видачі дозволів починається не з вибору моделей, а з опису чинного маршруту: хто приймає заяву, які інстанції погоджують, на якому кроці рішення впирається в ручну перевірку і скільки разів документи повертаються заявникові.
Чим точніше описано процес, тим менше припущень закладається в план впровадження і тим передбачуваніший результат на виході.
Щоб повернутися з оцінкою та планом робіт, а не із загальними міркуваннями, нам потрібні вихідні дані:
- схема чинного маршруту: етапи від приймання заяви до видачі документа і точки, де процес втрачає час;
- типи дозволів і ліцензій — у кожного свій набір перевірок і підстав для відмови;
- середній і піковий обсяг звернень, частка повернень на доопрацювання і повторних подань;
- перелік реєстрів та облікових систем, з якими звіряються дані: що кожна віддає і в якому вигляді;
- правила перевірки комплектності документів і ознаки, за якими заява відхиляється;
- вимоги до підпису, зберігання документів і захисту персональних даних;
- приклади типових звернень і кілька показових відмов з обґрунтуванням;
- обмеження за доступами, строками та етапністю запуску — що має працювати з першого дня.
Цього достатньо, щоб розділити перевірки: які автоматизуються повністю, які залишаються за співробітником з підказкою системи. Опишіть задачу — повернемося з оцінкою обсягу, планом впровадження за етапами та точками контролю на кожному з них.
