Это типовой сценарий. Он показывает, как Remolda подошла бы к ИИ-поддержке приёма заявок на разрешение на строительство в канадском муниципалитете среднего размера, что мы построили бы и что измеряли бы.
Ситуация
Представьте муниципалитет, где заявители на разрешение на строительство неделями ждут, пока кто-то посмотрит техническое содержание их дела. Заявка на жилой дом приходит пакетом: чертежи, планы участка, расчёты конструкций и сопроводительные документы. Небольшая команда проверяет каждый пакет на комплектность по муниципальному чек-листу, прежде чем его увидят инженеры и инспекторы.
Многие пакеты возвращаются со списком замечаний. Заявитель устраняет пробелы и подаёт снова, и проверка начинается заново. Некоторые дела проходят этот круг два-три раза. Тем временем заявители звонят узнать, на каком этапе их дело, и сотрудники отрываются от проверки, чтобы ответить.
Узкое место — проверка комплектности. Она идёт по чек-листу, поэтому большую её часть может поддержать ИИ.
Подход
Аудит (3 недели). Разбираем прошлые заявки в жилой, коммерческой и исторической категориях, работаем рядом с сотрудниками отдела разрешений и описываем каждый шаг от подачи до первой технической экспертизы. Исходными становятся два показателя: время от подачи до полного пакета и число повторных подач на одно дело.
Аудит также проверяет, одинаково ли сотрудники читают неоднозначные пункты чек-листа. Если нет, сначала пишется одна согласованная версия чек-листа, и она повышает единообразие ещё до появления ИИ.
Стратегия (4 недели). Решение состоит из трёх частей:
- Классификация документов и извлечение данных. Для каждого документа в пакете определяется тип, извлекаются ключевые значения: размеры, процент застройки участка, отступы от границ.
- Сверка с чек-листом. Извлечённые значения сравниваются с чек-листом для категории разрешения. Результат — структурированный отчёт: какие требования выполнены, каких не хватает и какие пункты должен решить человек.
- Ассистент по статусу для заявителей. Отвечает на типовые вопросы о статусе, замечаниях и следующих шагах через портал разрешений, а всё остальное передаёт сотрудникам.
Решение проверяют руководитель отдела разрешений, директор по планированию и служба ИТ-безопасности. Система работает рядом с существующим ПО для разрешений; его замена в проект не входит.
Внедрение, этап 1 (2 месяца): извлечение данных и отчёты по чек-листу. Механизм настраивается на прошлых заявках самого муниципалитета. Пакет, который отчёт показывает как полный, уходит на техническую экспертизу после подтверждения сотрудником. Для пакета с пробелами готовится черновик уведомления о недостатках простым языком со ссылкой на пункт чек-листа; сотрудник правит его и отправляет.
Первый месяц ИИ работает в теневом режиме. Сотрудники проверяют каждое дело сами, затем сравнивают свой вывод с отчётом ИИ. Расхождения разбираются и используются для настройки. Для перехода в рабочий режим нужен уровень точности, заранее согласованный с руководителем отдела разрешений.
Внедрение, этап 2 (2 месяца): ассистент по статусу. Заявители спрашивают о своём деле обычным языком и получают текущий статус из системы разрешений. Вопросы, требующие профессиональной интерпретации, нестандартные случаи и признаки недовольства передаются сотруднику.
Внедрение, этап 3 (1 месяц): интеграция. Смена статуса, уведомления о недостатках и одобрения автоматически отправляют заявителям уведомления.
Обучение (параллельно). Сотрудники отдела разрешений учатся читать отметки уверенности в отчёте, работать с неоднозначными пунктами и отмечать ошибочные оценки. Сотрудники приёмной и телефонной линии изучают границы ассистента и правила передачи вопросов людям.
Что мы измеряли бы
Каждый пункт ниже — целевой показатель, который мы установили бы вместе с муниципалитетом и сравнивали бы с исходными данными аудита. Величина каждой цели задаётся только после замера исходного уровня.
- Время от подачи до полного пакета.
- Число повторных подач на заявку до и после уведомлений о недостатках со ссылкой на чек-лист.
- Часы сотрудников на проверку комплектности в сравнении со временем на сложные дела и консультации заявителей.
- Доля совпадений между отчётом ИИ и решением сотрудника, с еженедельным отслеживанием.
- Звонки и письма о статусе в отдел разрешений.
Правила, которые задают рамки сценария
Решение о разрешении принимают главный строительный инспектор (chief building official) и сотрудники; ИИ готовит отчёты и черновики. Муниципалитеты Онтарио работают с информацией заявителей по Закону о муниципальной свободе информации и защите частной жизни (Municipal Freedom of Information and Protection of Privacy Act, MFIPPA), и проверка портала и ассистента на соответствие требованиям о защите данных входит в план. Правила и источники, которые мы проверяем, перечислены на странице для государственного сектора.
Главные выводы
1. Время уходит на шаг с чек-листом. ПО для разрешений обычно отслеживает дела и распределяет их. Проверку содержания, от которой зависит, пойдёт ли дело дальше, может поддержать ИИ.
2. Конкретные уведомления о недостатках сокращают круг. Уведомление, в котором названы недостающий размер и статья подзаконного акта, позволяет заявителю исправить всё за один раз. Расплывчатое уведомление ведёт к ещё одному кругу.
3. Видимость статуса важна так же, как скорость. Заявители спокойнее принимают ожидание, когда видят, где их дело. Ассистент по статусу и автоматические уведомления решают именно эту задачу.
Связанные материалы: ИИ для провинциального и муниципального управления, обработка документов и ассистенты поддержки клиентов.