Бережливое производство и ИИ: где потери убирает алгоритм, а не человек

В 1950 году на заводе Toyota произошло событие, из которого выросла вся производственная философия XX века. Компания оказалась на грани банкротства, и, чтобы выжить, ей пришлось придумывать способ делать машины без денег на запасные части, без больших складских запасов и без возможности переделывать брак.

Инженер Тайити Оно со временем сформулировал задачу так: производить ровно то, что нужно и когда нужно, ничего лишнего. Из этой задачи выросла система, которую сегодня знают под словом «бережливое производство», или lean. Её ядро — один вопрос: где мы теряем время, материалы и качество?

Семь видов потерь в этой системе расписывались по-разному, но суть одна: перепроизводство, ожидание, лишняя транспортировка, лишняя обработка, избыточные запасы, лишние движения людей и брак. Почти все эти потери — про людей и про необходимость принимать решения в реальном времени. И вот здесь начинается самое интересное.

Lean как система появилась не потому, что идея была грандиозной, а потому что у человека на заводе не было возможности видеть всё производство целиком. Мастер не мог одновременно знать, что творится у каждого из двадцати станков, сколько деталей лежит на входе и почему вчера выросла доля брака. Все классические инструменты lean — карточки канбан, сигналы андон, доски и стенды — это способы показать картину там, где её не видел человек.

Семьдесят лет спустя у производства впервые в истории появился практически полный взгляд на собственные процессы: датчики на оборудовании, системы класса MES, электронные наряды, телеметрия. Запрос сместился. Уже не «как сделать так, чтобы мастер видел больше», а «что делать с потоком данных, который идёт сам».

Ниже — честная разбивка по трём вопросам. Что говорят данные. Что реально делает алгоритм в цехе и на входе в него, а что нет. И что из этого можно проверить на своём производстве без миллионных бюджетов.

Сразу оговорюсь про подход, чтобы потом не было разочарования. Здесь не будет ни одного обещания вроде «внедрите ИИ и получите кратный рост». Все цифры в статье взяты из источников и приведены вместе с ограничениями: где это опрос производителей, где исследование на модели, а где данные одного конкретного рынка. Разница между этими тремя вещами — как раз то, что обычно теряется в материалах про ИИ в производстве, и именно из-за неё половина проектов заканчивается разговором «мы попробовали, не сработало».

Первое число — 42 %. Столько немецких промышленных компаний ещё в начале года заявили, что используют искусственный интеллект в производстве. Это не прогноз и не «по оценкам экспертов», а данные Digitalverband Bitkom, опубликованные 14 ноября 2025 года. Опрос проводился среди немецких промышленных предприятий — то есть речь о стране с сильной производственной школой.

Из того же материала есть второе число — 82 %. Столько руководителей этих предприятий считают, что применение ИИ в ближайшие годы станет решающим фактором конкурентоспособности отрасли. Здесь важна не сама цифра, а её контекст: 82 % — это не про то, что все уже внедрили, а про то, что вопрос перестали обсуждать как эксперимент и перевели в разряд условий работы.

Кстати, эти два числа стоит сложить вместе. Больше половины руководителей называют ИИ обязательным условием работы — при том что применяет его меньше половины. Разрыв между признанием важности и реальным внедрением и есть та задача, о которой имеет смысл писать: не «нужен ли нам ИИ», а «почему при общем согласии он не доходит до конкретных участков».

Третье число — самое интересное, потому что оно не из опроса, а из исследования на цифровом двойнике производства (Edelweiss Applied Science and Technology, т. 9, вып. 10, 2025). Авторы сравнили три сценария: обычные lean-практики, классическая автоматизация и когнитивная робототехника — то есть системы, которые не просто выполняют запрограммированные действия, а распознают ситуацию и принимают решение. Результат третьего сценария: доля дефектов ниже более чем на 70 %, время выполнения заказа меньше более чем на 30 %, энергопотребление на единицу продукции ниже примерно на 20 %. Одновременно растут показатели, которые в цехе считают ключевыми: выход годного с первого прохода и общая эффективность оборудования.

Теперь оговорки, без которых эти числа превращаются в рекламу.

Первая: результат «дефектов меньше более чем на 70 %» получен в симуляции на цифровом двойнике, а не в отчёте о внедрении на работающем заводе. Модель, которая предсказывает улучшение, и завод, который его получает, — разные вещи. Ценность исследования в другом: оно показывает, какие показатели вообще двигаются и в каком направлении, а не обещает конкретный процент вашему производству.

Вторая: сценарии сравнивали не «есть ИИ / нет ИИ», а уровни зрелости производства. Когнитивная робототехника в третьем сценарии работала внутри уже выстроенного lean-процесса, а не вместо него. Вывод звучит не как «поставьте роботов, и дефектов станет меньше на 70 %», а как «на плохо описанные процессы ИИ сверху накладывать бессмысленно».

Третья: исследование выполнено на материале украинских предприятий и прямо обсуждает задачу послевоенной модернизации. Это важно для калибровки ожиданий — цифры описывают производство с дефицитом людей и изношенным оборудованием, а не отлаженную высокоавтоматизированную линию.

Простой пример, знакомый любому, кто работал на производстве или рядом с ним.

Участок окраски. По плану он выдаёт около 400 изделий за смену, обычный уровень брака — два-три процента, и выявляют его на выходе. Каждое изделие проходит цикл: подготовка поверхности, грунт, сушка, финишное покрытие, контроль. Оборудование работает по своему режиму, время сушки задано технологом, поток деталей идёт по наряду.

Теперь представим, что на входе сменили поставщика грунта. Он другой по вязкости, разница небольшая. Партия уходит в работу. Через несколько часов выясняется, что покрытие ложится неравномерно и часть изделий придётся перекрашивать. Разбирательство показывает: причину можно было заметить в первые часы, если бы кто-то сопоставил отклонение параметров процесса с датой поступления новой партии. Но этим никто не занимался: вопрос «стабильно ли идёт процесс» в цехе решается визуальным осмотром и ежесменным отчётом.

Что произошло здесь с точки зрения lean? Сработали сразу несколько видов потерь. Лишняя обработка: детали сделали дважды. Избыточные запасы: пока искали причину, вход забили заготовками. Ожидание: заказ ждал переделку, следующий заказ ждал, пока освободится камера. И отдельная потеря, которую в семи видах обычно не выделяют в строку, хотя на практике она стоит дороже остальных: потеря качества информации. Никто не отследил связь между параметрами процесса и партией сырья.

Теперь посчитаем в деньги, чтобы разговор вышел из области теории. Партия — 400 изделий. Передел двадцати пяти из них — это возврат в начало цикла, то есть повторное использование материалов, повторная загрузка камеры и повторные человеко-часы маляра и контролёра. В отраслях средней сложности такие переделки регулярно стоят десятки тысяч рублей за инцидент: краска, растворители, подготовка поверхности, износ оборудования и, что важнее всего, часы, в которые камера не выпускала годную продукцию. Плюс сдвиг сроков по заказам, которые ждали эту камеру. Это оценка по типовым вводным, а не отраслевая статистика — подставьте свои цифры, порядок величины сохранится.

Отдельная строка, которую обычно не считают вовсе, — стоимость часа простоя узкого места. Если окраска — это узел, через который проходит весь поток, то каждый час, когда камера работает на переделку вместо планового заказа, стоит всей маржи, которая не была создана в других участках, ожидающих её освобождения. В производственной логике это можно приблизить так: час простоя узла умножается на стоимость часа его работы плюс на маржу пропущенных заказов, которые из-за этого сдвинулись. Тоже оценка, но её полезно сделать хотя бы один раз — она почти всегда оказывается больше, чем ожидают.

Классический lean отвечает на такой случай двумя инструментами. Первый — визуализация: показать отклонение так, чтобы его увидел человек. Второй — разбор: остановиться, найти причину, изменить стандарт работы. И то, и другое работает. Но у обоих есть общий предел: их выполняет человек, у которого уже есть сменная работа.

Здесь проходит главная линия разлома между старой и новой практикой, и она почти не в том, что принято называть внедрением ИИ.

Классический kaizen — это улучшение, которое инициирует человек: увидел проблему, предложил решение, договорились на недельной встрече, внедрили. Он требует собрания. Улучшение появляется рывками, по числу поводов, которые кто-то успел заметить.

Алгоритм устроен иначе: он не предлагает улучшить, он удерживает параметр. Смотрит на поток данных непрерывно, сравнивает с нормой и показывает отклонение раньше, чем оно успеет превратиться в партию брака. Это не то же самое, что прежний контроль качества. Контроль качества смотрит на изделие. Удержание параметра смотрит на процесс.

Вот как это выглядит конкретно, по трём применениям, каждое из которых закрывает свой вид потерь.

Прогнозная аналитика оборудования. Датчики снимают вибрацию, температуру и потребление мощности. Модель сравнивает фактические параметры с коридором нормы для этой машины и сигналит, когда подшипник начинает уходить от нормы, — за часы до поломки, а не тогда, когда линия уже встала. Экономия здесь приходит не от самой модели, а от того, что ремонт переносится из аварийного окна в плановое, между заказами. Закрываются две потери: ожидание и незапланированный простой узла.

Машинное зрение на контроле качества. Камера на линии контролирует геометрию и дефекты поверхности, а не человек на выходе. Это меняет главное: брак перестаёт накапливаться партией. Как только отклонение обнаружено на третьей детали, процесс останавливают, пока он не наработал ещё сорок штук в переделку. Закрываются лишняя обработка и избыточные запасы одновременно.

Согласование потока. Модель распределяет заказы так, что два участка не занимают одну тележку или одну камеру в одно и то же время, и показывает, где на самом деле узкое место. Это классическая логика планирования из lean, только решение обновляется несколько раз в смену, а не раз в сутки на планёрке. Закрывается ожидание на стыках между операциями.

Из примеров видно, что исследование про когнитивную робототехнику не описывает чудо. Оно описывает три вполне бытовые вещи: не гнать заведомо испорченное изделие, не занимать один ресурс двумя задачами и не ждать, пока узел сломается, чтобы вспомнить о нём.

У этого перехода есть последствие, о котором говорят редко. После того как узкое место найдено и закрыто, оно переезжает. Так же, как это происходит с любым улучшением в lean: оптимизировали окраску — узлом стала сушка или комплектовка. ИИ не отменяет этого закона. Он лишь сокращает время, за которое вы узнаёте, где теперь потеря.

Этот раздел приходится писать отдельно, потому что его почти всегда пропускают, а без него заводская команда просто не поверит остальному тексту.

Не заменяет инженера-технолога. Алгоритм видит отклонение и подсказывает связь. Решение о том, что менять в режиме обработки, принимает человек, потому что у него есть знания о материале, допусках и причинах, которые исторически не попадали ни в один датчик. Модель не заменит опыт, она сократит время до вопроса.

Не выбирает между качеством и скоростью. Это по-прежнему управленческое решение. Модель может показать, чем обернётся то или иное решение, но расставить приоритеты между сроком и себестоимостью — задача человека.

Не работает на хаосе. Если на участке нет описанных процессов, параметры не фиксируются, а брак не учитывается, обучать алгоритм не на чем. Данные сначала нужно собирать, и закупка платформы здесь не помогает: порядок в данных предшествует ИИ, а не следует за ним.

Не берёт на себя физику. Износ, брак от партии, ошибки логистики на уровне железного цеха — всё это остаётся у людей и оборудования. Алгоритм видит только то, что ему отдают датчики, справочники и наряды.

Не заменяет lean-мышление. Немецкие данные (Bitkom, 14.11.2025) показывают, что производство признало ИИ критичным фактором, но это взгляд на условие работы, а не на источник улучшений. Классическая последовательность «сначала найти потери, потом автоматизировать» остаётся рабочей; вопрос только в том, кто станет искать.

У семи видов потерь из lean есть любопытное свойство: они не знают границы завода.

Возьмём заявку, которая приходит на производственное предприятие. Форма на сайте, вечер, 21:40. Клиент пишет: «Нужна партия корпусов из нержавейки, 200 штук, интересуют сроки и цена, есть ли опыт с таким допуском». Это конкретный вопрос от человека, у которого уже есть бюджет и потребность.

Посмотрим на эту заявку не как на маркетинговую воронку, а как на производственный поток — так же, как смотрели бы на заготовку. Она пришла на вход. Её нужно обработать, то есть квалифицировать: понять, есть ли у нас подобный опыт, реально ли выдержать допуск, влезет ли партия в план на месяц. На решение влияют два разных человека — коммерческий отдел и технологическое бюро.

Дальше происходит то, что в цехе назвали бы перепроизводством, а в офисе называют «нормальной работой». Заявка лежит в почте до утра. Утром её открывает менеджер, отправляет в технологическое бюро, там отвечают через день, потом считают стоимость, потом уточняют у клиента то уточнение, которое можно было задать сразу. За неделю без ответа на первый вопрос клиент, скорее всего, уже получил ответ от двух других поставщиков.

Здесь важно сказать про тон. Мы не утверждаем, что любой медленный ответ для промышленности фатален. Для сложного заказа на месяц это нормально: клиент тоже не ждёт ответа за минуту. Проблема в другом: часть заявок вообще не получает ответа. Не потому, что человек плохой, а потому, что эта заявка попала в очередь, которой никто не управляет.

Есть исследование, которое много лет служит ориентиром в вопросе скорости первого ответа. Это Lead Response Management Study, автор Джеймс Олдройд из MIT Sloan, 2007 год, выборка — более 15 000 веб-лидов и порядка 100 000 звонков. Согласно ему, ответ в первые пять минут даёт примерно в 100 раз больше шансов дозвониться до лида и примерно в 21 раз больше шансов его квалифицировать по сравнению с ответом через тридцать минут. Первоисточник читался через разбор со ссылкой на исследование, поэтому метку достоверности ставим честно: это данные по звонкам и по западному рынку.

Дополняет картину публикация Harvard Business Review (март 2011 года, данные 2 241 американской компании): ответ в пределах часа давал примерно в семь раз больше шансов на содержательный разговор с человеком, принимающим решения, чем ожидание «на час дольше». А по сравнению с теми, кто отвечал через сутки, разница была примерно в 60 раз. Страница HBR в автоматическом доступе не открывается — это тоже часть честной картины, а не деталь для сноски.

Применять эти цифры к производственному заказу нужно с той же осторожностью, что и к цеху. Они измеряют факт контакта, а не продажу; первые два числа — из исследования 2007 года. Но закономерность в них видна отчётливо и объясняется не магией: человек, который вечером оставил вопрос, ещё держит тему в голове. Утром у него уже три других ответа.

Соединяем. В производстве lean убирает ожидание на стыках между операциями. Ровно те же потери живут на стыках между коммерческим отделом, технологическим бюро и клиентом. Разница только в том, что на заводе для этого поставили андон и наладили карточки, а в офисе по-прежнему ждут, пока кто-то из очереди заметит.

Какие обращения в разных нишах бывают типовыми, а какие всегда требуют инженера, мы разбираем отдельно — в разделе «Аналитика ИИ-консультанта и ниши применения».

Ни один из этих шагов не требует бюджета и подрядчика. Зато каждый проверяет, есть ли вообще задача, которую стоит автоматизировать.

Шаг 1. Опишите поток обращений так, как описывали бы производственный процесс. Возьмите тридцать последних входящих обращений — из формы, чата, почты и звонков. Для каждого зафиксируйте, через какие точки он прошёл и где задержался: у кого лежал, кто должен был ответить, что мешало. Именно на этом этапе обычно выясняется, что половина обращений вообще не имеет владельца.

Шаг 2. Отделите содержательный ответ от подтверждения. «Ваша заявка принята» — это не обработка обращения, это фиксация факта поступления. Считайте только ответы по существу вопроса: есть ли опыт, реально ли соблюсти допуск, какая цена, какой срок. Разница между этими двумя категориями обычно и объясняет, почему заявок много, а заказов мало.

Шаг 3. Найдите узел, а не весь поток. Не пытайтесь оптимизировать всё сразу — это самая частая ошибка промышленных проектов. В потоке почти всегда есть одна точка, где задержка больше всего: ожидание согласования, ручной перенос данных, отсутствие шаблона ответа на пять частых вопросов. Работайте с ней и считайте эффект. Для цеха это тот же принцип: сначала узкое место, потом всё остальное.

Шаг 4. Проверьте, есть ли данные. Если процессы не фиксируются — в CRM нет статусов, заявки не размечены, время не отмечается, — сначала появляется учёт. Только после него появляется возможность что-то предсказывать. Это не бюрократия, а условие: алгоритм не работает лучше, чем данные, которые ему отдали.

Шаг 5. Посчитайте деньги на бумаге и остановитесь. Умножьте месячный бюджет привлечения на долю обращений, которые не получили содержательного ответа за сутки. Получится цена потерь. Если она меньше стоимости любой автоматизации — не покупайте автоматизацию, начните с регламента: дежурный на телефоне, шаблоны ответов, уведомление дежурному вместо почты, которую никто не читает. Иногда этого достаточно.

И отдельно про ожидание эффекта. Японское Persol Research Institute (2026, национальная выборка) показало вещь, которую стоит держать в голове: на уровне отдельных задач генеративный ИИ ускоряет работу в среднем на 16,7 %, но рабочее время реально сократилось лишь примерно у четверти пользователей (25,4 %), а 61,2 % высвобожденного времени вернулись в работу, и в основном — в текущую рутину.

Это стоит прочитать дважды тем, кто планирует «освободить людей с помощью ИИ». Освободить недостаточно: решите заранее, на что вы направите освободившееся время. Иначе оно уйдёт в тот же самый поток, и через месяц окажется, что ничего не изменилось.

Перестраивать не нужно, достаточно того, что уже есть, при одном условии: процессы должны быть описаны, а данные о них — собираться. Если у вас есть схема потока, нормы времени и учёт брака, этого достаточно, чтобы начать. Если нет — ИИ придётся отложить и сначала навести порядок в этих трёх вещах.

С самой измеримой потери. На небольшом производстве это почти всегда не оптимизация станка, а ожидание на стыках: между заявкой и ответом, между заказом и запуском в работу, между выявлением брака и решением о причине. Посчитайте по каждой точке время, найдите худшую — она и будет стартовой.

Обещать такое конкретному заводу никто не может, включая авторов исследования. Результат получен в симуляции на цифровом двойнике, где сравнивались уровни зрелости процесса, а не два способа управления одним и тем же производством. Правильное чтение: направление движения подтверждено, а размер эффекта определяется вашим процессом и вашими данными.

Не просто можно — обычно это и есть самый короткий путь к измеримому результату. На входе потока потери видны быстрее: заявка либо получила ответ, либо нет, и время первого ответа считается в секундах, а не в сменах. Пока в цехе собирают данные, на входе уже можно посчитать потери и убрать ожидание.

Тогда проверьте одну вещь: сколько обращений за последний месяц не получили содержательного ответа в течение суток. Обычно ответ на этот вопрос оказывается неприятным сюрпризом — не потому, что в компании плохо работают, а потому, что этот показатель почти никто не измеряет. Начните с него, и станет ясно, есть задача или нет.

Ставить так вопрос честнее, чем обходить его. Из собранных данных видно другое: там, где ИИ встраивается в уже описанный процесс, он чаще забирает рутинные операции внутри смены — обходы, контроль, сверку — и меняет содержание работы, а не отменяет её. Людей освобождают не модели, а решения руководителей о том, как перестроить участок. Поэтому планировать переход стоит вместе с людьми, а не после них: иначе первый же слух о внедрении будет стоить вам сопротивления на всех следующих этапах.

Что вы можете прямо сейчас: взять тридцать последних обращений, выписать для каждого время поступления и время первого содержательного ответа и посмотреть, в какой день недели и в какой час у вас теряется больше всего. У вас получится не оценка «примерно», а конкретная цифра потерь на входе производственного потока.

Получить демо на своём сайте — покажем, как выглядит первый ответ на вопрос клиента там, где сейчас заявка ждёт смены или следующего рабочего дня. Как это работает на сайте целиком — на главной странице LeanAgent, а стоимость и состав тарифов — в разделе тарифы.

Читайте также: Правило первой минуты: почему горячий лид остывает до звонка · Чат-бот на сайте: что он реально даёт и когда от него больше вреда · ИИ на российских заводах: что уже работает, а что пока только в презентациях · Бот или живой оператор: считаем, что дешевле — и когда дешевле не значит лучше · Все статьи блога →