Закон автоматизации был законом окупаемости: почему разовую задачу теперь можно автоматизировать, если её дёшево проверить
Проект, в котором автоматизировать оказалось нечего
Меня подключили к проекту внедрения ИИ в крупной организации уже после его запуска. Платформа была развёрнута, первое частное техническое задание согласовано, команда готовилась переходить к реализации.
В техническом задании объектом автоматизации назывался "паспорт аналитической задачи". Под этим документом понималось описание работы: откуда взять данные, каким образом их объединить, какие показатели рассчитать и в каком виде представить итог руководству.
На первый взгляд паспорта выглядели как готовый каталог процессов для автоматизации. Однако последовательное изучение документов быстро показало обратное. Большинство задач выполнялось один раз в год. Другие запускались по индивидуальному запросу - без понятного графика, фиксированного числа повторений и гарантированного срока следующего выполнения.
Ещё важнее было то, что сами правила работы постоянно менялись. В новом году могли измениться форма отчёта, перечень показателей, источники информации и адресат результата. Даже если однажды удавалось описать алгоритм достаточно точно, не было уверенности, что через год он останется прежним.
Формально всё необходимое присутствовало: реальные документы, настоящие задачи, работающая технологическая платформа и заинтересованные участники. Не было лишь главного - устойчивого потока операций, который оправдывал бы автоматизацию.
Три признака пустого проекта
У подобных инициатив обычно есть три характерных признака.
Первый - отсутствие измеримого объёма. Само наличие "аналитической задачи" ещё ничего не говорит о масштабе работы. Сравним: "подготовить аналитический материал" - слишком расплывчатая формулировка, а "классифицировать 8 тысяч обращений по семи категориям в год" - уже подходящий объект для автоматизации.
В рассматриваемом проекте большинство задач выполнялось несколько раз или вообще единично. Количество трудозатрат часто не измерялось, поэтому никто не мог уверенно сказать, сколько времени действительно удастся сэкономить.
Второй признак - отсутствие однозначного способа проверить результат. В документах встречались формальные показатели вроде "не менее 80% информации должны быть релевантными". Но на практике участники по-разному понимали, что именно считать релевантным.
Один эксперт принимал материал, другой находил в нём лишние сведения. Модель могла спутать однофамильцев, неправильно интерпретировать термин или перенести значение из смежной области. Часть ошибок действительно была связана с ограничениями ИИ, однако главная проблема заключалась в отсутствии единого эталона проверки.
Промпты, цепочки обработки и перекрёстная проверка одной модели другой позволяли немного повысить качество. Но они не устраняли фундаментальный спор между экспертами. Если люди не договорились о критериях правильного результата, технология не сможет сделать эти критерии объективными.
Третий признак - пилот не получает реальный рабочий поток. Подключить систему к настоящим задачам означает взять ответственность за её решения. Если организация не умеет быстро и недорого проверять результат, безопаснее оставить ИИ на тестовой выборке.
Так пилот превращается в постоянный эксперимент: он работает на искусственных данных, демонстрирует отдельные удачные примеры, но не становится частью повседневного процесса.
Почему старый закон автоматизации работал
В традиционном понимании автоматизировать стоило стабильную, повторяющуюся и трудоёмкую работу. Это правило появилось не случайно.
Раньше создание одной автоматизированной операции требовало аналитика, разработчика, тестировщика, специалистов по внедрению и обучения пользователей. На реализацию уходили недели или месяцы. Поэтому технология должна была многократно повторять одну и ту же операцию, иначе затраты на разработку не окупались.
Именно здесь находились три ключевые переменные:
- повторяемость;
- трудоёмкость;
- стабильность процесса.
Если задача выполнялась редко, менялась от случая к случаю или занимала мало времени, автоматизация оказывалась дороже ручной работы. Нарушение этого правила нередко приводило к созданию дорогой системы, которой пользовались два человека, а после увольнения одного из них проект фактически прекращался.
Что изменил искусственный интеллект
Генеративный ИИ резко снизил стоимость первого шага. Теперь не всегда нужно заранее разрабатывать полноценную информационную систему, формализовать каждый сценарий и месяцами готовить интеграции.
Модель способна получить текстовое описание, найти данные, составить черновик, классифицировать документы, подготовить сводку или предложить структуру отчёта. Благодаря этому автоматизировать стало возможно даже то, что раньше считалось слишком нерегулярным.
Но снижение стоимости создания решения не отменяет необходимости контроля. Наоборот, главным ограничением становится цена проверки.
Новая формула выглядит так: разовую или нестабильную задачу можно автоматизировать, если результат легко, быстро и недорого оценить человеком или другой системой.
Иными словами, теперь важна не только стоимость генерации результата, но и стоимость обнаружения ошибки.
Кейс: миграция, которую нельзя было автоматизировать полностью
Хороший пример - перенос данных между старыми и новыми системами. На первый взгляд такая работа кажется идеальной для ИИ: документы можно распознать, поля сопоставить, отсутствующие значения восстановить, а записи перенести автоматически.
Однако в реальной миграции встречаются неполные карточки, разные форматы дат, исторические сокращения, дубли, устаревшие справочники и неоднозначные названия. Модель способна предложить наиболее вероятное соответствие, но не всегда может доказать, что оно верно.
Если каждая ошибка приводит к финансовым, юридическим или операционным последствиям, проверка каждой записи становится обязательной. Тогда предполагаемая экономия быстро уменьшается.
Полная автоматизация в таком случае может быть неоправданной, а частичная - полезной. ИИ способен отсеять очевидные случаи, сгруппировать сомнительные записи, подсветить противоречия и подготовить очередь для специалиста. Человек проверяет не весь массив, а только рискованные элементы.
ИИ автоматизирует ИТ-службу, а не всю организацию
На практике внедрение ИИ часто быстрее всего даёт результат внутри ИТ-подразделения. Там уже существуют стандартизированные процессы, журналы событий, шаблоны заявок и понятные критерии успеха.
Модель может классифицировать обращения пользователей, предложить решение типовой проблемы, сформировать описание инцидента, проверить конфигурацию или подготовить черновик документации. Ошибка обычно выявляется быстро: заявитель сообщает, что проблема не решена, либо система не проходит техническую проверку.
В других подразделениях ситуация сложнее. Юристы, закупщики, специалисты внутреннего контроля и аналитики нередко работают не по устойчивому процессу, а по поручениям. Содержание задач может быть похожим, но каждый раз меняются форма, контекст, сроки и требования руководителя.
Для ИИ это означает отсутствие стабильного шаблона. Для организации - невозможность заранее определить, где заканчивается допустимая помощь и начинается опасная ошибка.
Почему офисные инструменты важнее большой ERP-системы
Парадоксально, но максимальный эффект от ИИ часто появляется не в масштабной ERP-платформе, а в привычных офисных инструментах.
Текстовые документы, электронные таблицы, почта и презентации ежедневно используются практически всеми сотрудниками. Именно там накапливается значительный объём рутинной работы: сведение данных, подготовка справок, редактирование формулировок, составление протоколов и поиск информации.
ИИ может встроиться в эту среду без многолетнего проекта внедрения. Сотрудник получает черновик, проверяет его и доводит до нужного качества. При этом организация не обязана заранее формализовать весь процесс.
Однако такой подход требует понятных правил безопасности. Нельзя без ограничений загружать в публичные модели персональные данные, коммерческую тайну, сведения о клиентах и документы с ограниченным доступом. Любая программа автоматизации должна включать контроль данных, разграничение прав и журналирование действий.
Где новая формула не работает
Автоматизация не оправдывает себя, если ошибка дороже ручной работы. Критичными могут быть медицинские решения, юридические выводы, финансовые расчёты и действия, влияющие на безопасность.
Не подходит ИИ и для задач, где результат нельзя проверить за разумное время. Если специалисту требуется изучить весь исходный массив дольше, чем подготовить ответ самостоятельно, экономического эффекта не возникает.
Проблема также появляется при отсутствии владельца результата. Должен быть конкретный человек, который принимает решение, отвечает за итог и может отменить рекомендацию модели. Формула "так предложил ИИ" не заменяет управленческой ответственности.
Наконец, не стоит автоматизировать хаос только потому, что технология стала доступнее. Если исходные данные неструктурированы, термины не определены, а правила меняются ежедневно, сначала нужно привести в порядок саму работу.
Что делать организации
Начинать следует не с выбора модели, а с инвентаризации операций. Для каждой задачи полезно зафиксировать:
1. сколько раз она выполняется;
2. сколько времени занимает ручная работа;
3. какие данные используются;
4. насколько часто меняются правила;
5. что считается правильным результатом;
6. сколько стоит проверка ошибки;
7. кто несёт ответственность за итог.
После этого процессы можно разделить на три группы. Первая - полностью автоматизируемые: у них большой объём, понятные правила и дешёвая проверка. Вторая - подходящие для совместной работы человека и ИИ. Третья - неподходящие для автоматизации, поскольку риск или стоимость контроля слишком высоки.
Пилот нужно запускать не на красивой демонстрационной выборке, а на реальном ограниченном потоке. Лучше выбрать один тип документов, конкретное подразделение и небольшой период, заранее установив показатели успеха.
Важно измерять не только точность модели. Не менее значимы время проверки, доля исправлений, количество повторных обращений, стоимость обработки и удовлетворённость сотрудников. Иногда модель отвечает не идеально, но сокращает работу специалиста вдвое - это уже практический результат.
Главный вывод
Старый закон автоматизации не исчез. Он просто перестал быть полной картиной. Раньше главным вопросом была окупаемость разработки: достаточно ли часто повторяется операция, чтобы оправдать создание системы.
Теперь стоимость создания решения значительно ниже, поэтому на первый план вышла другая величина - цена проверки. Разовую задачу можно автоматизировать, если человек способен быстро понять, где модель ошиблась, и безопасно исправить результат.
ИИ не превращает любую деятельность в конвейер. Он делает доступной автоматизацию отдельных интеллектуальных действий, которые раньше были слишком дорогими для формализации. Поэтому успех определяется не самим наличием модели, а качеством процесса вокруг неё: ясными критериями, ответственным владельцем, реальными данными и недорогим контролем.
Автоматизировать следует не всё подряд, а то, где стоимость ошибки меньше стоимости ручной работы, а проверка результата остаётся простой и понятной.
