LLM в операционной эффективности: где инструмент помогает, а где создаёт иллюзию решения

LLM в операционной эффективности всё чаще используются для анализа документов, подготовки отчётов, генерации гипотез, поддержки FMEA, RCA, MSA и других OpEx-инструментов. Но большие языковые модели не заменяют измерение процесса, экспертную проверку, ОПИ и ответственность владельца решения. В статье разбираем, где LLM действительно создаёт пользу, а где уверенный ответ модели может стать источником управленческой ошибки.

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

Это ожидание особенно соблазнительно для OpEx. Операционная эффективность всегда работает с дефицитом ясности. Нужно быстрее понимать, где возникают потери, почему растёт брак, где скрыта перегрузка, какие процессы нестабильны, почему KPI выглядят зелёными, а реальность остаётся тяжёлой.

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

Но именно здесь возникает главный риск.

LLM хорошо работает с языком. OpEx работает с процессом.

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

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

Её ценность возникает там, где она помогает быстрее собрать свидетельства, структурировать информацию, расширить список гипотез, применить утверждённый алгоритм или подготовить управленческий материал.

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

LLM-use case и OpEx-use case — не одно и то же

Первое методологическое различие, которое важно зафиксировать: LLM-use case и OpEx-use case — не одно и то же.

LLM-use case начинается с вопроса:

“Что может делать LLM?”

Из этого рождаются понятные цифровые сценарии: чат с документами, поиск по регламентам, summary совещаний, генератор отчётов, помощник инженера, помощник руководителя, написание VBA или Python-кода, черновики A3 и Problem Statement, подготовка презентаций, обучающие материалы.

Многие из этих сценариев полезны. Они экономят время, снижают рутинную нагрузку, ускоряют подготовку материалов и делают знания более доступными. Но сами по себе они ещё не являются OpEx-улучшениями.

OpEx-use case начинается с другого вопроса:

“Какая потеря должна измениться?”

Например:

снизить простой оборудования;
сократить повторные измерения;
уменьшить COPQ;
повысить OTIF;
снизить количество дефектов;
сократить время переналадки;
уменьшить ручные эскалации;
снизить скрытую перегрузку мастеров;
ускорить прохождение заказа;
уменьшить потери от нестабильного планирования.

В OpEx результатом является не текст, не рекомендация и не презентация. Результатом является изменение измеряемой потери: меньше брака, меньше простоев, ниже COPQ, выше OTIF, короче цикл, ниже ручная нагрузка, выше стабильность процесса, лучше безопасность, меньше повторных измерений, меньше скрытых управленческих эскалаций.

Поэтому LLM-кейс становится OpEx-кейсом только тогда, когда у него есть пять обязательных элементов:

конкретная потеря;
решение, которое должно стать лучше;
единица анализа;
данные или свидетельства;
механизм проверки результата.

Если этих элементов нет, LLM может дать полезный цифровой сервис, но не операционное улучшение.

Например, “LLM пишет отчёт по качеству” — это LLM-use case. Он может быть полезен, но сам по себе не снижает брак.

А вот другой сценарий: LLM извлекает из тысяч комментариев операторов повторяющиеся условия дефектов, после чего команда проверяет гипотезы, выделяет режимы процесса и запускает ОПИ по снижению конкретного вида брака. Это уже потенциальный OpEx-use case.

Разница принципиальная.

Глобальная и локальная LLM: разные возможности, разные риски

Для практического применения в OpEx важно различать глобальные и локальные LLM.

Глобальная LLM работает с широким внешним знанием. Она хорошо объясняет методы, сравнивает подходы, помогает войти в незнакомую отрасль, предлагает структуры, формулирует гипотезы, проверяет логику рассуждения, помогает с текстом, кодом, отчётами и обучающими материалами. Её сила — широта.

Но глобальная LLM почти никогда не знает локальную операционную реальность компании. Она не видит фактическую работу смены, не знает неформальные обходы, не понимает скрытую нагрузку мастеров, не видит реальную очередь в лаборатории, не знает, какие показатели “держатся руками”, а какие действительно отражают стабильный процесс.

Её типовая ошибка — слишком общее, но хорошо звучащее решение.

Локальная LLM, наоборот, может быть подключена к внутренним документам, регламентам, инструкциям, оргструктурам, базам знаний, отчётам, протоколам, журналам, корпоративной терминологии и внутренним данным. Её сила — контекст.

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

Поэтому локальная LLM знает не саму компанию, а прежде всего то, как компания описала саму себя.

Ключевое различие:

Глобальная LLM рискует быть слишком общей.
Локальная LLM рискует быть слишком уверенной в корпоративной версии реальности.

Выбор между глобальной и локальной моделью не решает главный вопрос. Главный вопрос — как встроить модель в контур проверки реальной работы.

Что LLM реально умеет в OpEx

LLM не является самостоятельным OpEx-инструментом в строгом смысле. Она не измеряет процесс, не наблюдает работу, не проводит фотографию рабочего дня, не подтверждает причинность, не знает реальную загрузку людей, не видит скрытые компромиссы между качеством, сроками, затратами и безопасностью. Она не несёт ответственности за последствия управленческого решения.

LLM работает с представлениями о реальности: текстами, данными, описаниями, классификациями, формулировками, историческими примерами, документами и вопросами.

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

Базовая формула простая:

LLM может работать с описанием процесса. OpEx должен менять сам процесс.

Но в правильно выбранной роли LLM может быть очень сильной.

Она снижает стоимость доступа к знаниям. Помогает находить нужные фрагменты, объяснять документы, сравнивать версии, выделять противоречия, готовить краткие выжимки, переводить технический язык на управленческий и наоборот.

Она расширяет поле гипотез. Команда часто застревает в первом объяснении: “виноват материал”, “виновато оборудование”, “не хватает людей”, “плохое планирование”, “нужна автоматизация”. LLM может помочь увидеть альтернативные объяснения. Но правильный статус таких предложений — не вывод, а гипотеза; не причина, а кандидат в причину; не решение, а направление проверки.

Она помогает формализовать мышление. Может привести рассуждение к форме: проблема → факт → потеря → единица анализа → гипотеза → проверка → действие → владелец → метрика результата.

Она может применять утверждённые алгоритмы. Если компания имеет корректно разработанный алгоритм MSA, SPC, FMEA, оценки потерь, проведения Gemba Walk или подготовки A3, LLM может помогать пользователям применять этот алгоритм к конкретной ситуации.

Она ускоряет упаковку результата в действие: стандарт, инструкцию, учебный материал, структуру совещания, план внедрения, список рисков, критерии контроля, текст для руководителей или объяснение для сотрудников.

Но во всех случаях действует одно правило:

Если предложение LLM нельзя проверить через данные, эксперта, ОПИ или безопасный пилот, его нельзя превращать в операционное действие.

LLM как отраслевой собеседник

Одно из сильных применений LLM в OpEx — быстрый вход в незнакомую предметную область.

OpEx-специалист может хорошо владеть методами улучшений, но не быть экспертом в конкретном бизнесе: здравоохранении, ретейле, лесопереработке, машиностроении, логистике, сервисных процессах, энергетике, строительстве или производстве потребительских товаров.

В такой ситуации LLM может выступать как первичный отраслевой собеседник: помочь описать типовой процесс, предложить возможные потери, дать пример метрик, подсказать типовые риски, показать возможную структуру scorecard или карты процесса.

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

Но такой ответ нельзя принимать как готовую scorecard. Его нужно пропустить через два фильтра.

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

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

Правильная модель:

LLM даёт первичную отраслевую структуру → OpEx-эксперт проверяет методологическую корректность → команда процесса проверяет фактическую применимость.

LLM в Fishbone, FMEA, RCA и MSA

LLM может быть особенно полезна в аналитических сессиях, где команде нужно расширить поле гипотез, проверить полноту рассуждения и не застрять в первом объяснении.

В Fishbone / Ishikawa LLM может предложить возможные причины по категориям People, Machine, Method, Material, Measurement, Environment, Management / Planning. Она может напомнить о слабости измерений, нестабильности входного материала, конфликте планирования и мощности, неформальных обходах, разном понимании стандарта, перегрузке сменного мастера, отсутствии временных меток или неправильной единице анализа.

Но результат LLM в Fishbone должен иметь статус кандидата в причину, а не причины.

В RCA LLM может быть полезна как критик логики: не перепутан ли симптом с причиной, не остановилась ли команда слишком рано, есть ли альтернативные объяснения, доказана ли причинная связь, какие данные нужны для проверки, какое действие устраняет причину, а не только компенсирует симптом.

Но LLM не должна назначать root cause. Корневая причина появляется не из связного текста, а из проверенной связи между событием, условием, механизмом и результатом.

В FMEA LLM может помочь подготовить черновик: возможные failure modes, эффекты отказа, потенциальные причины, существующие controls, рекомендуемые действия, вопросы для команды. Она может напомнить методическую логику Severity, Occurrence и Detectability.

Но LLM не должна самостоятельно выставлять оценки для конкретного процесса. Она не знает фактическую частоту отказа, реальную силу контроля, качество обнаружения, последствия для клиента, особенности оборудования и историю отклонений.

В MSA LLM полезна не как автор методики, а как помощник в применении утверждённой логики. Она может объяснить, зачем нужен Gage R&R, какие данные требуются, что означает плохая повторяемость, чем повторяемость отличается от воспроизводимости.

Но вывод “что делать дальше” допустим только в том случае, если LLM работает по заранее утверждённому алгоритму компании.

Ключевая формула:

LLM может расширять анализ, но не должна закрывать анализ.

LLM как исполнитель практических задач

Не вся ценность LLM должна быть связана с большими трансформациями. В OpEx много практической работы, где LLM может быстро снизить рутинную нагрузку и повысить качество подготовки материалов.

Типовые задачи:

написать VBA-макрос для консолидации файлов;
подготовить Python-скрипт для очистки или объединения данных;
сделать summary совещания;
переписать проблему в формате Problem Statement;
подготовить черновик A3;
оформить charter проекта;
сделать структуру отчёта;
подготовить вопросы для Gemba Walk;
сделать чек-лист аудита;
перевести технический вывод на язык менеджмента;
собрать учебный кейс для мастеров.

В таких задачах LLM часто даёт быстрый и реальный эффект, потому что результат можно проверить. Код можно протестировать. Summary можно сверить с исходным протоколом. Problem Statement можно проверить по фактам. A3 можно разобрать с командой. Чек-лист можно опробовать на пилоте.

Но и здесь действует ограничение:

LLM может готовить форму, но владелец процесса отвечает за содержание.

LLM хорошо делает черновики. OpEx должен превращать черновики в проверенные решения.

LLM как оператор утверждённых алгоритмов

Одна из наиболее перспективных зон применения LLM — помощь пользователям в применении уже утверждённых алгоритмов.

Если алгоритм разработан экспертами, проверен на реальных кейсах, утверждён владельцами процесса и имеет понятные границы применения, LLM может стать удобным интерфейсом к этому алгоритму.

Примеры: алгоритм проведения MSA, подготовки A3, выбора типа контрольной карты, классификации потерь, проведения Gemba Walk, оценки FMEA, запуска ОПИ, проверки готовности данных, эскалации производственного отклонения.

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

Но это работает только при трёх условиях:

алгоритм утверждён экспертами;
входные данные проверены;
результат имеет владельца.

Ключевая формула:

LLM может быть оператором утверждённой логики. LLM не должна быть невалидированным автором критичной логики.

Почему алгоритмы нельзя отдавать LLM без экспертов

В OpEx алгоритм — это не просто инструкция. Это делегированная логика принятия решений.

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

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

Опасность состоит не только в том, что LLM может ошибиться. Опасность в том, что ошибочный алгоритм начинает масштабировать ошибку. Один неверный ответ модели — локальный риск. Неверный алгоритм, внедрённый как стандарт, — системный риск.

Разработка алгоритмов должна выполняться экспертами, находящимися на 1–3 уровня компетентности выше тех, кто будет эти алгоритмы применять.

Пользователь алгоритма часто работает на уровнях “понять → применить → заполнить → выполнить шаг”. Разработчик алгоритма должен работать выше: проанализировать ограничения, оценить риски, создать логику, проверить её на кейсах, обучить других, определить границы применимости.

Любой критичный алгоритм должен пройти четыре проверки:

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

LLM может помогать на каждом этапе. Но утверждать алгоритм должны люди, которые отвечают за последствия его применения.

ОПИ и обратимость решений

Любое предложение LLM, которое влияет на реальный процесс, должно проходить практическую проверку. Это можно описывать как ОПИ — опытно-промышленное испытание, практический пилот или ограниченную проверку изменения в контролируемых условиях.

Главное назначение ОПИ — отделить правдоподобную рекомендацию от работающего решения.

До проверки предложение LLM — не решение, а гипотеза.

ОПИ должен отвечать на пять вопросов:

что именно меняем;
какую потерю хотим изменить;
как измеряем эффект;
какой риск создаём;
можно ли откатить изменение.

Вопрос обратимости должен стать обязательным фильтром.

Обратимые решения — новый формат отчёта, шаблон A3, структура summary, VBA-инструмент, пилотный дашборд, учебный материал, дополнительный чек-лист. Здесь LLM может играть активную роль, потому что ошибка обычно обнаруживается быстро и исправляется дешево.

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

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

Короткая формула:

Чем ниже обратимость решения и выше цена ошибки, тем меньше право LLM влиять на действие.

Governance: как не превратить LLM в теневого руководителя

LLM не должна становиться теневым субъектом управления. У модели нет ответственности за последствия. Ответственность всегда остаётся у человека, функции или коллегиального органа.

Governance нужен не как бюрократия, а как система защиты от ложной ясности.

Он должен ответить на главный вопрос:

где LLM имеет право помогать, а где она не имеет права решать.

Для этого нужны базовые правила.

Классификация применений по уровню риска.
Низкий риск — работа с формой и текстом. Средний риск — аналитическая поддержка. Высокий риск — рекомендации, влияющие на процесс. Критический риск — решения по людям, безопасности, производственным параметрам, качеству, инвестициям, клиентским обещаниям и оргструктуре.

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

Разделение факта, гипотезы и рекомендации.
“В должностных инструкциях есть пересечение функций” — наблюдение по документам. “Роли дублируются” — гипотеза. “Одну роль можно сократить” — рекомендация высокого риска, требующая проверки фактической работы.

Владелец решения.
У каждого LLM-сценария должен быть владелец: производство, качество, технология, ТОиР, OpEx, HR, финансы, безопасность, юридическая функция или комитет по изменениям.

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

Запрет на “AI said so”.
Фраза “AI рекомендовал” не должна быть основанием для действия. Правильная формула: LLM помогла сформулировать гипотезу; гипотеза проверена данными; риск оценён; владелец решения подтвердил; ОПИ показал результат.

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

LLM и производительность труда

Тема производительности труда особенно чувствительна, потому что здесь легко перепутать три разных вопроса:

где есть лишняя работа;
где есть избыточная численность;
кого можно сократить.

Это не один и тот же вопрос.

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

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

Третий вопрос — кадровое решение. Оно имеет высокую социальную, операционную и репутационную цену, а его последствия часто трудно откатить.

LLM может быть полезна в первом вопросе. Она может быть ограниченно полезна во втором. Но она не должна напрямую отвечать на третий.

Ключевой принцип:

LLM можно использовать для поиска лишней работы. LLM нельзя использовать как самостоятельный механизм определения лишних людей.

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

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

Правильная последовательность:

сначала убрать лишнюю работу;
потом стабилизировать процесс;
потом измерить фактическую загрузку;
потом проверить перераспределение функций;
и только после этого обсуждать численность.

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

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

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

Кейс: можно ли использовать LLM для сокращения 10% HC?

Рассмотрим обобщённый пример. Компания ставит задачу сократить 10% работников в производстве, включая управленческий персонал. В LLM загружаются списочный состав, оргструктура и должностные инструкции. На основании этих данных модель предлагает позиции, которые можно сократить.

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

В такой постановке LLM не решает задачу операционной эффективности. Она решает задачу текстового отбора кандидатов под заранее заданную цель.

Модель работает не с трудом, а с описанием труда. Она анализирует похожие должностные инструкции, похожие названия функций, наличие управленческих уровней, размытые формулировки обязанностей, потенциально автоматизируемые задачи, формальные пересечения между ролями, поддерживающие или административные функции.

После этого она может сформировать убедительный список:

позиция → причина возможного сокращения → кому передать функции → ожидаемый эффект → риски.

Но такой список не является доказательством избыточности. Он является нарративом, построенным на формальном описании организации.

Самая точная формула:

LLM не находит лишних людей. Она находит должности, которые легче всего описать как лишние на основании документов.

Главная опасность — сокращение не избыточности, а скрытой управляемости. В производственной системе часть ролей может выглядеть вторичной или поддерживающей, но фактически удерживать стабильность процесса: мастер закрывает отклонения между планом, качеством и фактической сменой; диспетчер знает, какие планы невыполнимы; координатор собирает разорванные данные; специалист по качеству предотвращает риск отгрузки; аналитик вручную восстанавливает картину, которую ИТ-система не показывает; планировщик компенсирует нестабильность поставок, оборудования и клиентских приоритетов.

В должностной инструкции эта работа может выглядеть как “координирует”, “контролирует”, “участвует”, “анализирует”, “обеспечивает взаимодействие”. Для LLM это может быть сигналом слабой конкретики. В реальности это может быть описание роли, которая закрывает сложность между функциями.

Поэтому под удар могут попасть не самые бесполезные люди, а самые плохо описанные роли.

Правильный вопрос должен звучать не так:

“Кого можно сократить, чтобы получить минус 10%?”

Правильный вопрос:

“Какая работа не создаёт ценности, может быть устранена, упрощена, автоматизирована или перераспределена без ухудшения качества, безопасности, сроков, клиентских обязательств и управляемости?”

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

Правильный процесс:

LLM-анализ документов → формирование гипотез → фактическое измерение работы → разделение работы по типам → проверка перераспределения → оценка риска и обратимости → ОПИ → решение по процессу → возможное решение по численности.

Ключевой вывод:

Без измерения трудозатрат LLM сокращает не избыточность, а видимость избыточности.

Итоговая позиция

LLM нужно использовать в операционной эффективности. Но использовать её нужно не как замену OpEx, а как усилитель OpEx-мышления, экспертизы и проверяемого действия.

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

LLM может ускорить этот путь. Но она не должна его подменять.

LLM должна быть:

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

LLM не должна быть:

судьёй истины;
теневым консультантом;
автоматическим руководителем;
автором непроверенных критичных методик;
источником решений по людям, безопасности, качеству, инвестициям и производственным параметрам.

Базовые правила применения:

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

Самая короткая формула:

LLM предлагает. Эксперт проверяет. ОПИ подтверждает. Владелец отвечает.

LLM создаёт ценность в OpEx не тогда, когда заменяет мышление, а тогда, когда делает мышление быстрее, шире и проверяемее.

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

Если модель просто выдаёт уверенный ответ без проверки реальности — это не OpEx, а новая форма управленческой иллюзии.