«Совершенство достигается не тогда, когда уже нечего добавить, а когда уже нечего убрать». — Антуан де Сент-Экзюпери
Пару дней назад у меня вышло видео о том, что пишут консультанты в августе 2026 года — такой обзор публикаций и идей, которые сейчас активно обсуждают на рынке. А сегодня продолжаю разбирать новые инструменты и подходы, которые, на мой взгляд, действительно стоит не просто посмотреть, а попробовать приземлить на реальную работу.
Один из таких подходов — Lean AI Sprint.
И мне он нравится не потому, что в названии есть модное AI. А потому, что в нём есть то, чего часто не хватает большинству AI-инициатив: здравый смысл, короткий цикл, привязка к реальному процессу и жёсткий вопрос — где именно здесь создаётся ценность, а где мы просто автоматизируем хаос.
Однажды в Toyota сформулировали очень простую, но сильную мысль: хочешь улучшить систему — сначала пойди туда, где реально происходит работа. Не в переговорку. Не в красивый PowerPoint. Не в отчёт для совета директоров. А туда, где человек реально делает задачу руками.
Раньше это был цех, станок, линия, склад.
Сегодня во многих офисных и сервисных процессах это экран сотрудника: почта, CRM, ERP, Excel, мессенджер, папка с документами, корпоративный портал, тикетная система и ещё десять вкладок браузера.
Именно там почти всегда и прячутся настоящие потери:
- ожидание ответа или согласования;
- поиск нужной информации по нескольким системам;
- ручное копирование данных;
- дублирование работы;
- ошибки из-за невнимательности или разрыва между системами;
- переделки;
- «исключения», которые почему-то уже давно стали нормой.
Вот в этом месте и начинается разговор про Lean AI Sprint.
Что это вообще такое
Если говорить по-человечески, Lean AI Sprint — это короткий, сфокусированный цикл, в котором команда не просто ищет, куда бы прикрутить AI, а сначала разбирает конкретный процесс, находит потери, фиксирует базовые метрики, упрощает логику работы и только потом решает, где AI действительно даст эффект.
То есть последовательность такая:
- сначала понять, где теряется время, качество, деньги или клиент;
- потом посмотреть, как работа реально выполняется;
- затем отделить нужные шаги от лишних;
- и только после этого встроить AI туда, где он реально усиливает процесс.
Ключевая идея здесь очень простая: process first, AI second.
Это важная мысль, потому что сегодня многие компании двигаются наоборот. Они начинают не с процесса, а с инструмента. Покупают copilot, запускают внутренний чат, делают красивый demo day, собирают каталог use cases — а потом оказывается, что экономического эффекта почти нет.
Почему?
Потому что AI встроили поверх процесса, который изначально был кривым, перегруженным исключениями, с плохими данными и кучей ручных обходных путей.
В результате получается не прорыв, а просто более дорогая версия старого бардака.
В чём логика Lean AI Sprint
Мне кажется, этот подход особенно полезен для руководителей и команд, которые устали от двух крайностей.
С одной стороны — от AI-хайпа, где каждый второй обещает «революцию», «полную замену функций» и «агентов, которые всё сделают сами».
С другой — от классической корпоративной тяжеловесности, когда любой новый инструмент сначала обрастает комитетами, governance-моделями, стратегическими инициативами, десятками интервью и 120 слайдами roadmap, а потом бизнес уже потерял интерес.
Lean AI Sprint — это попытка пройти между этими крайностями.
Не строить многолетнюю абстрактную программу «AI transformation», а взять один живой процесс и быстро ответить на несколько вопросов:
- где здесь ценность;
- где здесь потери;
- что можно убрать вообще;
- что можно упростить;
- что можно стандартизировать;
- где хватит обычной автоматизации;
- а где AI действительно полезен.
И дальше не спорить в теории, а собрать пилот и посмотреть результат на реальных данных.
С чего начинается спринт
Нормальный Lean AI Sprint начинается не с вопроса «какой AI нам внедрить?», а с вопроса: какой бизнес-процесс у нас реально болит?
Например:
- слишком долго обрабатываются клиентские запросы;
- менеджеры тратят много времени на подготовку коммерческих предложений;
- команда закупок вручную разбирает слишком много однотипных писем и документов;
- договоры долго проходят согласование;
- в производстве слишком много времени уходит на поиск причин отклонений;
- техподдержка перегружена ручной маршрутизацией и ответами на типовые вопросы.
То есть входная точка — не «хотим AI», а «есть понятная боль».
Это очень меняет качество разговора.
Потому что когда команда приходит с формулировкой «нам нужен AI для продаж», это почти ни о чём. А вот когда формулировка звучит так: «подготовка стандартного предложения занимает в среднем 48 часов, при этом большая часть времени уходит на ожидание данных, ручное заполнение систем и согласования» — с этим уже можно работать.
Digital gemba: самый недооценённый шаг
Дальше, на мой взгляд, начинается самая интересная часть — digital gemba.
То есть нужно не обсуждать процесс по памяти, а реально смотреть, как сотрудник выполняет последние 5–10 кейсов. Какие письма приходят, какие поля приходится искать вручную, где копируются данные, где человек ждёт, где сверяется с шаблоном, где пишет коллеге, где открывает Excel «на всякий случай», потому что системе он не до конца доверяет.
Это невероятно приземляющее упражнение.
Очень часто уже в первый час становится видно, что:
- одна и та же информация вводится в несколько систем;
- значительная часть времени уходит не на решение задачи, а на ожидание;
- многие исключения предсказуемы и повторяются;
- сотрудники обходят официальный процесс, чтобы просто быстрее сделать работу;
- критические знания живут в голове у одного-двух опытных людей;
- часть шагов вообще не создаёт ценности, но все к ним привыкли.
И вот здесь возникает важный момент: иногда после такого наблюдения становится ясно, что лучший следующий шаг — вовсе не AI.
Иногда сначала нужно:
- убрать лишнее согласование;
- переделать входную форму;
- навести порядок в справочниках;
- сделать нормальную интеграцию между системами;
- стандартизировать шаблоны;
- определить чёткие правила маршрутизации.
И только потом подключать AI.
Это не слабость подхода. Наоборот, это его сила. Он не заставляет использовать AI ради галочки.
Какие метрики нужны
Ещё одна причина, почему мне нравится Lean AI Sprint: он требует baseline.
То есть нельзя честно говорить об улучшении, если никто не знает, как процесс работал до этого.
Обычно полезно зафиксировать хотя бы такие вещи:
- lead time — общее время от входящего запроса до результата;
- touch time — сколько времени люди реально работают с задачей;
- queue time — сколько задача ждёт в очереди;
- first pass yield — какая доля кейсов проходит с первого раза без возвратов;
- rework — сколько переделок;
- defect rate — сколько ошибок;
- throughput — сколько единиц процесса проходит за период;
- cost per transaction — сколько стоит обработка одного кейса.
Без этого любое обсуждение быстро превращается в набор субъективных ощущений:
«стало вроде быстрее»,
«людям нравится»,
«кажется, стало удобнее»,
«demo был отличный».
Для пилота этого недостаточно.
Если AI действительно даёт эффект, это должно быть видно в метриках. Например:
- время обработки сократилось с 36 часов до 12;
- число ручных касаний снизилось с 18 до 7;
- доля задач без переделки заметно выросла;
- команда стала обрабатывать больше объёма без расширения штата;
- клиент получает ответ в тот же день, а не через несколько дней.
Вот это уже язык операционного результата.
Где AI действительно даёт смысл
Есть очень полезная последовательность мышления:
- Убрать лишнее.
- Упростить оставшееся.
- Стандартизировать повторяемое.
- Автоматизировать правила и интеграции.
- И только потом — усиливать AI там, где есть вариативность, неструктурированные данные, поиск, классификация, генерация текста или принятие решений в рамках понятных границ.
Вот в таких задачах AI обычно особенно полезен:
- извлечение данных из писем, PDF и вложений;
- классификация обращений, инцидентов, рекламаций и документов;
- суммаризация длинной переписки;
- подготовка черновиков ответов, предложений и отчётов;
- поиск по базе знаний и технической документации;
- сравнение договоров с шаблонами;
- первичная маршрутизация кейсов;
- выявление повторяющихся причин дефектов или отклонений;
- поддержка сотрудников в принятии типовых решений.
Но здесь важно не впадать в магию.
AI не должен быть «чёрным ящиком, который сам всё решит». Для каждого use case нужны понятные ответы:
- где AI может действовать автоматически;
- где требуется подтверждение человека;
- какие кейсы обязательно эскалируются;
- что считается ошибкой;
- какая система остаётся источником истины;
- что происходит, если модель ошиблась или недоступна.
Когда эти ответы есть, AI становится частью рабочего механизма, а не красивой игрушкой.
Как выбрать первый кейс
Для первого спринта я бы не брал самый амбициозный процесс компании. Лучше выбрать что-то достаточно болезненное, но управляемое.
Хороший кандидат обычно имеет несколько признаков:
- заметный объём;
- повторяемость;
- цифровой след;
- понятного владельца процесса;
- ощутимую бизнес-боль;
- возможность быстро проверить гипотезу;
- относительно контролируемые риски.
Очень часто хорошими стартовыми кейсами оказываются:
- обработка стандартных входящих запросов;
- рекламации и customer service;
- quote-to-order;
- обработка договоров;
- закупочные заявки;
- счета и документы;
- внутренние сервисные запросы;
- поиск знаний и подготовка черновиков в экспертных функциях.
Плохой первый кейс — это обычно что-то слишком политически чувствительное, слишком редкое, слишком сложное или завязанное на десятки систем и конфликтующих интересов.
Первый спринт нужен не чтобы доказать величие AI. Он нужен, чтобы научиться правильно строить механику изменений.
Что должно получиться в конце
На выходе Lean AI Sprint должен появиться не просто список идей и не просто demo.
Должно появиться более зрелое понимание процесса:
- как он реально работает сейчас;
- где находятся потери и узкие места;
- какие шаги можно убрать;
- какие стандартизировать;
- где есть смысл в классической автоматизации;
- где AI даёт наилучший эффект;
- как выглядит future state;
- какой пилот стоит запускать первым;
- по каким метрикам оценивать успех.
И очень важно, что после пилота решение не обязано быть только одно — «масштабируем на всю компанию».
Вариантов всегда три:
- Scale — масштабируем, если эффект подтверждён;
- Fix — дорабатываем, если идея правильная, но есть проблемы с данными, UX, интеграцией или правилами;
- Stop — останавливаем, если кейс не даёт достаточной ценности.
И вот это, кстати, очень здоровая логика.
Потому что умение быстро остановить слабую инициативу — не провал, а признак зрелости.
Почему этот подход сейчас особенно актуален
Мне кажется, в 2026 году мы входим в очень важную фазу AI-рынка.
Эйфория никуда не исчезла, но у бизнеса всё чаще возникает более взрослый вопрос: а где реальная ценность?
Не количество лицензий.
Не число обученных сотрудников.
Не количество пилотов.
Не размер AI-программы.
А именно реальное изменение процесса, экономический эффект, скорость, качество, пропускная способность и управляемость.
И вот здесь Lean AI Sprint выглядит очень своевременным подходом.
Он возвращает разговор с уровня абстракций на уровень конкретной работы.
Не «давайте внедрим AI в функцию», а:
- какой у нас процесс;
- где в нём потери;
- что мешает потоку;
- что можно убрать;
- где автоматизация даст эффект;
- где AI действительно усилит людей и систему;
- как быстро это проверить на практике.
Это, по сути, очень консультантский, очень операционный и очень прагматичный способ думать про AI.
Без религиозной веры в технологию.
Без наивного отрицания технологии.
И без бесконечных разговоров «когда-нибудь потом».
Главное
Если совсем коротко, Lean AI Sprint — это хороший antidote от двух болезней сразу:
- от бессмысленного AI-хайпа;
- от медленной корпоративной парализации.
Он заставляет сначала увидеть реальный процесс, потом убрать потери, затем спроектировать более разумный future state и только после этого встраивать AI туда, где он действительно полезен.
И, пожалуй, самая важная мысль здесь звучит очень просто:
не автоматизируйте потери.
Сначала найдите их.
Потом уберите лишнее.
Потом упростите поток.
И только затем решайте, нужен ли здесь AI, обычная автоматизация или вообще достаточно просто перестать делать лишнюю работу