В страховании сейчас распространенный сценарий: руководству приходит гениальная идея «внедрить AI», оно спускает его на функциональных директоров — «придумайте, что у вас автоматизировать». Директор идёт к ChatGPT, описывает процесс, получает уверенный ответ «вам подойдёт LLM-агент». Идёт к вендору — вендор приносит презентацию и ценник. Идёт к консультантам — те делают аудит и тоже находят, что предложить.
И ни один из этих советчиков не скажет «не делайте, не окупится». У LLM это встроено в обучение — она вежливая и полезная. У вендора это бизнес-модель. У консультанта это контракт.
Получается, что у руководителя функции — реальная проблема с реальными деньгами — нет источника совета, который умеет говорить нет.
Я сделала такой источник, или мне это только кажется (смайл). Это бесплатный диагностический сканер для функций страховой компании, без LLM в контуре обработки и без регистрации. Он принимает ответы пользователя про конкретный процесс и говорит, в какую зону этот процесс попадает — зелёную (делать), жёлтую (гибрид с человеком в петле) или красную (не автоматизировать, экономика не сходится) + предлагает релевантные решения.
С чего я вдруг такой альтруист — делать бесплатные инструменты? Конечно, у меня свой интерес, я готовлю образовательный курс для страховщиков, а умные маркетологи говорят, что сейчас без лидмагнита никуда. Дай человеку бесплатную ценность, и если окажется полезно, он придёт. Но мой корыстный интерес не отменяет того, что в сканер вложена двадцатилетняя экспертиза в страховых процессах и опыт аналитика. Это самостоятельный инструмент, которым можно пользоваться и на курс ко мне не идти и даже контакты не оставлять, PDF с результатами скачивается и без этого.
Так как я хотела сделать хорошо, то прежде чем сканер увидел первого пользователя, мне пришлось тестировать его трижды — каждый раз он на чём-то да выдавал фигню. Эту статью я пишу как раз про эти истории — что выдавал и как это чинила. Чтобы вы не набивали мои шишки. Предположу, что кейс будет полезен для того, кто строит диагностические инструменты, и для всех, кто этими инструментами пользуется.
Почему не «спросите у LLM»
Сначала короткое обоснование, почему сканер не на LLM. Это важно, потому что иначе вопрос «а почему ты не сделала просто чат-бота поверх GPT» висит и портит всё дальнейшее.
Воспроизводимость. Диагностика, которая на одних и тех же ответах выдаёт сегодня одно, а завтра другое — бесполезна как управленческий артефакт. Совет директоров не примет «AI так сказал», им нужно «при таких-то параметрах процесс попадает в такую-то зону по таким-то правилам».
Объяснимость. Решение «этот процесс в красной зоне» должно сопровождаться «потому что вот эти три признака не отмечены». LLM объяснение генерирует постфактум, и оно может не совпадать с реальной причиной. Это окей для творческой задачи, для управленческого вывода — мимо.
Цель — чтобы из самого результата было видно, почему ответ именно такой, а не иначе. Поэтому рекомендации формируются детерминированно из ответов пользователя по жёстким правилам. Дальше — как именно, и где это давало сбои на ранних версиях.
Архитектура: три слоя, каждый о своём
Сканер устроен из трёх слоёв, и каждый отсекает что-то своё, чтобы следующий слой не работал впустую.
Рис. 1. Архитектура сканера. Слой-фильтр отсекает редкие/малозатратные/уже автоматизированные процессы. Слой экспресс-оценки разбрасывает остальные по трём зонам. Слой детального разбора даёт профиль и рекомендации.
Слой-фильтр. Три вопроса в начале — как часто выполняется процесс, сколько уходит трудозатрат, есть ли уже автоматизация. Если процесс редкий, или малозатратный, или уже полностью автоматизирован — он отсекается как «не приоритет», и в детальный разбор не идёт. Это банально, но без этого слоя сканер тратил бы 18 вопросов на процессы, которые в принципе не стоит анализировать.
Слой экспресс-оценки. Для каждого процесса функции — несколько чекбоксов про применимость (объём, повторяемость, чистота данных) и сложность (исключения, цена ошибки). На пересечении этих двух осей зона: применимость высокая и сложность низкая — зелёная, применимость низкая или сложность очень высокая — красная, остальное — жёлтая. Грубая, но быстрая разметка по всей функции, чтобы получить скрининг функции за пять минут или найти процессы, которые копать дальше.
Слой детального разбора. Любой процесс, который захочется разобрать глубже, проходит через расширенный опросник. Из ответов считаются индексы (рутинность, готовность данных, оргзрелость, текстовая работа, классификация, визуал, многошаговость). Из индексов определяется профиль — Рутинёр, Текстовик, Визуал, Классификатор, Многорукий или Незрелый. Для каждого профиля заранее заготовлены подходящие классы инструментов с оценкой сложности, эффекта, окупаемости.
Сценариев работы с этим два. Если у вас в функции десяток процессов и нужен быстрый скрининг — проходите по чекбоксам всех, получаете карту приоритетов и копаете дальше только зелёные. Если хочется разобрать всё подробно — ничто не мешает пройти детальный опросник по каждому из десяти, ограничений нет.
На бумаге всё это выглядело логично. Дальше три истории, в каждой из которых что-то шло не так.
Баг №1: инструмент рекомендовал AI тому, кому сам сказал «не автоматизируй»
Логика выбора зоны и логика выбора инструмента работали параллельно, не зная друг о друге.
Зона определялась по применимости и сложности. Инструмент определялся по своим правилам — есть ли в процессе классификация, насколько чистые данные, сколько исключений. По отдельности обе функции вели себя разумно. В сборке получалось так: процесс попадал в красную зону (применимость низкая, экономика не сходится, не автоматизировать) — и одновременно получал в графе «подходящий инструмент» что-то вроде «LLM-ассистент с человеком в петле».
Прогон всех комбинаций ответов показал, что красная зона и подзона «жёлтая с высокой ценой ошибки» выдавали одинаковые инструменты в восьми ветках. Я это поймала на тестах — гоняла сканер с помощью Claude Code по разным комбинациям ответов, смотрела, что выдаёт, и в одном из проходов увидела, что процесс с красной зоной в графе «инструмент» получил «LLM-ассистент с человеком в петле». Если бы это попало в пользователя, я бы не обрадовалась.
Чинила тривиально: ввела явный guard. Если зона красная — поле «инструмент» всегда «не автоматизировать, экономика не сходится», независимо от прочих сигналов. То же для уровня инвестиций — для красной зоны смысла его считать нет.
Рис. 2. Баг №1. До починки: процесс попадал в красную зону, но получал рекомендацию AI-инструмента — два модуля выдавали противоречащие выводы. После guard: для красной зоны инструмент не считается, согласованность обеспечена явным правилом.
Инженерный урок: две части системы, которые логически связаны, не обязательно согласованы между собой автоматически — их надо связывать явным правилом. Это базовая вещь, но она требует, чтобы кто-то держал в голове всю систему сразу — а это редкое умение, чаще каждую часть пишут отдельно и потом удивляются.
Управленческий урок: Если ваша аналитика в одной таблице говорит «нет», а в другой «вот как сделать» — это серьёзная несогласованность, она подрывает доверие к выводу целиком, даже если каждая таблица сама по себе верна. Бдим и проверяем.
Баг №2: «классификация по числам» и «классификация по тексту» — это не одно и то же
Был один чекбокс в опросе: «есть ли в процессе задача классификации или прогноза». Он сделан с лучшими намерениями — отделить процессы, для которых может пригодиться машинное обучение, от тех, где хватит роботизации и правил.
Проблема в том, что «классификация» — это два совершенно разных мира.
Классификация по структурным полям — это классический ML. Есть таблица с числовыми и категориальными признаками, есть метка, обучаем модель. В зависимости от объёмов, можно вообще обойтись «малой кровью» — моделью на локальном ПК с минимумом затрат.
Классификация по неструктурированному тексту — это уже NLP или LLM. Совсем другой класс инструментов, другой бюджет, другие ограничения (тот самый 152-ФЗ для облачных моделей, например). Если на входе у вас текст обращения клиента — классический ML на нём работает плохо, нужна языковая модель.
Обеим ситуациям сканер советовал «классический ML — задача классификации/прогноза». Для процессов с табличными данными это было верно. Для процессов вроде «классификация обращений в контакт-центр по тематике» — совершенно неверно, потому что нет никакой таблицы с признаками, есть тексты, и нужен NLP.
Эти два класса задач различаются и по ограничениям. Классический ML на структурированных данных страховщик чаще всего разворачивает у себя на собственной инфраструктуре, никаких внешних сервисов не нужно. А вот NLP-обработка текстов клиентских обращений сразу упирается в 152-ФЗ: текст обращения часто содержит персональные данные, и отправить его в облачную LLM нельзя, нужно on-prem-решение или российский аналог. Это совсем другой бюджет, другие сроки, другая архитектура. Поэтому одна рекомендация на оба случая не просто неверна по технике — она ещё и вводит в заблуждение по стоимости и срокам.
Починка: разделила чекбокс на два. Один — «есть задача классификации». Второй — «работа с неструктурированным текстом или документами». Их сочетание переключает рекомендацию между разными классами инструментов. Сейчас четыре ветки вместо одной, и каждая ведёт к своему инструменту с реалистичными для него ограничениями.
Инженерный урок: один признак, под которым прячутся две разные сущности — частая ошибка проектирования опросников. Если ответ «да» может означать две разные вещи с разными последствиями — это два вопроса, а не один. Узнаваемо для всех, кто проектирует анкеты, формы, схемы данных, поля справочников.
Управленческий вывод: когда вы получаете отчёт «у нас X% клиентов недовольны обслуживанием», полезно спросить, из какого вопроса это X% получено, потому что недовольны работой медицинского колл-центра и недовольны рекомендациями врача для ДМС два совершенно разных «недовольны».
Баг №3: «Рутинёр» как мусорка для всего непонятного
Профиль процесса в детальном разборе определялся так: смотрим на индексы (рутинность, текст, классификация, визуал, многошаговость) и сравниваем с порогами. Если индекс «текст» выше порога — Текстовик. Если «классификация» — Классификатор. Если «визуал» — Визуал. И тд. Если ничего не дотянуло — Рутинёр.
Звучит разумно, но по факту реальные процессы часто смешанного типа.
Возьмем процесс, у которого индекс «классификация» вышел на 55, индекс «текст» — на 53, индекс «рутинность» — на 48. По жёстким порогам он не дотянул ни до Классификатора (нужно было выше), ни до Текстовика. Падает в Рутинёра. И получает рекомендации вроде «RPA на типовые шаги» — хотя на самом деле там и текст, и классификация, и нужен совсем другой инструмент.
Хуже того: процесс с classification=55 и text_focus=53 при следующем прогоне (где, скажем, веса чуть-чуть сместились) мог уже наоборот вылезти в Классификатора. То есть результат «дребезжал» на границе порога. Любой управленческий инструмент, который на близких данных выдаёт разные ответы — повод его доработать.
Чинила двумя действиями.
Первое: вместо жёстких порогов сравниваю топ-1 и топ-2 среди специализированных индексов. Если топ-1 явно опережает топ-2 — назначаю специализированный профиль. Если разрыв маленький — «специализации не выделились». Это устраняет пограничные колебания.
Второе: «Рутинёр» теперь присваивается только если индекс рутинности сам по себе достаточно высокий, не падает туда всё подряд по остаточному принципу. Если рутинность тоже низкая — даю профиль «Незрелый», то есть «фундамент процесса требует доработки до того, как вообще говорить про автоматизацию».
Инженерный урок: жёсткие пороги создают сомнительные колебания на границах. И если у вас есть «профиль по умолчанию» — проверьте, не превратился ли он в мусорку для всего, что не подошло куда-то ещё.
Управленческий урок: если ваша сегментация клиентов или процессов имеет группу «и все остальные» — она чаще всего самая большая и самая бесполезная. Я об этом уже писала в первой статье про дерево решений и граф работ, но этот баг сегментации вообще много где вылезает и заслуживает внимания аналитика.
Баг №4, непроцессный: технически верная и экономически абсурдная рекомендация
Сканер давал технически корректные ответы, которые управленчески были неверны.
Пример. Есть процесс «анализ убыточности по узким сегментам» — выполняется раз в квартал, занимает у аналитика день, делается 5 раз в год. Пользователь честно отмечает «есть классификация» (там действительно строится модель по сегментам). Сканер видит «классификация + чистые данные» и радостно рекомендует ML-классификацию или, если данных мало, ML с разметкой.
Формально верно. Реально — может не окупиться. Машинное обучение на 5 прогонах в год — это инфраструктура, разметка, поддержка модели, мониторинг качества. Стоимость такая, что разумнее посадить аналитика и пусть он раз в квартал делает руками. Сканер этого не учитывал, потому что ответы про частоту и объём использовались только в фильтре «приоритетно — нет», а на выбор инструмента не влияли.
Починка: каждая рекомендация теперь размечена по стоимости (дёшево / средне / дорого). Если процесс мелкий по объёму и трудозатратам, а в рекомендациях есть дорогой инструмент — в начале списка предупреждений появляется явный warning: «эти инструменты окупаются только при тысячах операций в год». Сам инструмент из списка не удаляется — пользователь видит весь спектр и видит экономическое ограничение отдельно, и сам решает.
Инженерный урок: техническая применимость и экономическая целесообразность — разные оси, обе обязательны. Инструмент, который считает только первую, выдаёт корректные, но бесполезные для бизнеса ответы.
Управленческий урок: если ваша AI-стратегия не считает экономику каждой инициативы — через год вы потратите бюджет на пилоты, два из которых сдохнут, два дадут невнятный результат, и один, может быть, окупится.
Что из этого следует
Все четыре бага (или нюанса, как хотите), если присмотреться, имеют одну природу. Сканер слишком охотно говорил «да» — каждый отдельный модуль был оптимистом по умолчанию. Та же болезнь, что у LLM-советчика и у вендора с презентацией — просто в детерминированном виде.
Может возникнуть вопрос: а чего ты такая умная, на этапе разработки методологии сканера это всё не предусмотрела? Обычно его задают те, кто реальной архитектуры не проектировал. В моей корпоративной жизни даже ТЗ от исходного запроса бизнеса отличается как банан от помидора, а уж итоговое архитектурное решение и подавно. Так что умными быть и критиковать — хорошо, но практика она такая: сначала сделали, потом по тестам поняли, что что-то не то, и починили. Хорошо, если вообще починили, а не отдали в прод как есть.
В общем, на мой взгляд, такого сканера страховщикам не хватало, и он будет полезен хотя бы как верхнеуровневая оценка «на подумать».
Сканер открыт, без регистрации, можно прогнать свою функцию: datadriven-course.ru/scanner. Если найдёте, что он где-то всё ещё говорит глупости — буду благодарна, если расскажете в комментариях, где именно. Допускаю, что могла предусмотреть не все косяки; хорошо бы их вычислить раньше, чем они кого-нибудь подведут.
Маленькая техническая ремарка для пользователей Safari. Если открываете на iPhone или Mac в Safari, можно увидеть предупреждение «мошеннический сайт». Это ложное срабатывание — Google Safe Browsing сайт проверил чисто, VirusTotal 0 из 91, у Яндекса тоже зелёный. Apple на три запроса не отвечает. Открывается без предупреждения в Chrome, Firefox, Яндекс.Браузере или со смартфона на Android. Подробнее в моём вопросе на Q&A — если знаете решение, буду благодарна.
Надеюсь, эта статья будет полезна аналитикам и интересующимся страхованием.
