Предметно-ориентированное мышление при цифровой трансформации предприятия

На первый взгляд кажется, что ИИ как раз для этого и нужен. Он умеет читать тексты, сопоставлять фрагменты, строить объяснения, отвечать на вопросы, формулировать выводы. Он может взять регламент, протокол совещания, выгрузку из ERP, письмо от поставщика, кусок инструкции и собрать из них связный ответ. Именно эта способность сначала производит сильное впечатление. Возникает ощущение, что предприятие наконец получило универсальный интерфейс к собственной сложности.

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

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

Обычно это разочарование объясняют технически. Говорят: модель недостаточно обучена; промпт был плохо написан; данных было мало; данные были грязными; нужно подключить модель к базе; нужно дать ей больше контекста; нужно использовать более новую версию; нужно применить RAG, векторный поиск, агентный контур, классификатор документов, корпоративную базу знаний. Во всех этих объяснениях есть часть правды. Но они не исчерпывают проблему. [9]

Технический слой действительно важен. Плохой промпт ухудшает ответ. Неполные данные ограничивают рассуждение. Некачественный поиск по документам приводит к неверным фрагментам. Прямое подключение к ERP может дать больше фактов. Но даже если всё это улучшить, остаётся более глубокий вопрос: что именно ИИ должен считать предметом рассуждения?

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

Управленческая причина галлюцинаций в предприятии часто состоит не в том, что ИИ плохо думает, а в том, что предприятие не дало ему предметов для мышления. Оно дало тексты, формы, таблицы, отчёты, названия процессов, документы системы менеджмента качества, показатели и регламенты. Но оно не задало явную карту бизнес-предметов: что возникает, что изменяется, что передаётся, что фиксируется, что контролируется, что измеряется и что становится основанием для управленческого решения. [10]

У предприятия, как правило, много видимых слоёв. Есть регламенты, положения, инструкции, маршрутные карты, описания бизнес-процессов, организационная структура, роли, зоны ответственности. Есть ERP-система, где ведутся заказы, документы, справочники, регистры, отчёты, настройки, статусы, взаиморасчёты, остатки, движения и аналитики. Есть KPI, бюджетные формы, отчёты руководителя, управленческие панели, протоколы совещаний, корректирующие мероприятия. Есть СМК — система менеджмента качества, в которой хранятся процедуры, записи, формы, доказательства выполнения требований и результаты проверок.

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

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

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

Чего часто нет у предприятия в явном виде? Нет реестра таких предметов. Нет описания их состояний. Нет переходов между состояниями. Нет различения, где предмет находится в ERP, где — в бумажной форме, где — в Excel, где — во внешнем кабинете, где — только в голове ответственного сотрудника. Нет связи между предметом и процессом. Нет связи между предметом и процедурой. Нет связи между предметом и ролью. Нет связи между предметом и KPI. Нет связи между предметом и нормативным требованием. Нет понимания, какие носители допустимы, какие являются временными, а какие должны стать управляемыми.

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

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

ERP также не заменяет предметный мир. В первом упоминании зафиксируем термин: ERP — Enterprise Resource Planning, класс корпоративных систем управления ресурсами предприятия. В этой книге ERP-система рассматривается как важный прикладной и учётный контур: она фиксирует значимые факты, документы, движения, статусы, расчёты, аналитику, права, настройки, маршруты и отчёты. Без такого прикладного и учётного ядра зрелое управление предприятием невозможно. [1]

Но ERP-объект не равен бизнес-предмету. Документ, справочник, регистр, отчёт, настройка, статус или аналитика могут быть носителями состояния предмета, но сами по себе они ещё не раскрывают предметную модель. Один бизнес-предмет может жить сразу в нескольких ERP-объектах. Один ERP-объект может участвовать в жизни нескольких предметов. Часть предмета может быть в ERP, часть — в регламенте, часть — в СМК, часть — во внешней системе, часть — в фактической практике предприятия. Поэтому прямой доступ LLM к базе ERP может помочь ответить на вопрос «что записано?», но не гарантирует ответа на вопрос «что это значит?».

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

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

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

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

За кадром той концепции остался слой, который тогда ещё не был необходим в явном виде для массового входа в ERP-системы, но теперь становится необходимым. Это слой бизнес-предметов, предметной онтологии, графа знаний, LLM как интерфейса к графу, доменных ядер памяти и цифрового двойника деятельности предприятия. Раньше этот слой можно было держать как внутреннюю методологическую интуицию опытного архитектора. Теперь его нужно вынести наружу и описать. [7]

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

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

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

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

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

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

Финальная формула главы такова: бизнес-предмет — носитель смысла и результата; процесс — маршрут изменения состояния бизнес-предмета; ERP — система фиксации, контроля и анализа этих изменений; искусственный интеллект предприятия — способность рассуждать о предметах, их состояниях, связях и последствиях. LLM не является источником истины. LLM является интерфейсом к графу знаний. ERP-данные отвечают на вопрос «что записано?». Граф знаний отвечает на вопрос «что это значит, как предмет движется, почему он изменил состояние и что делать дальше?».

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

Глава 10. Галлюцинация ИИ как управленческий симптом

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

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

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

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

Предприятие — не набор текстов. Предприятие — предметная система. В нём существуют заказы, запасы, партии, потребности, обязательства, лимиты, маршруты, отклонения, рекламации, платежи, производственные задания, первичные документы, состояния качества, статусы готовности, управленческие решения. Эти сущности живут во времени, меняют состояние, проходят через роли, документы, ERP-объекты, СМК-записи, отчёты и управленческие решения.

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

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

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

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

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

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

Если предмет «потребность» не описан, ИИ может начать рассуждать только по документам. Он увидит заказ поставщику и решит, что потребность уже обеспечена. Он увидит остаток на складе и решит, что закупка не нужна. Он увидит заявку и решит, что она автоматически стала обязательством поставщика. Но управленчески это разные состояния. Потребность может быть выявлена, подтверждена, согласована, включена в план обеспечения, закрыта заказом поставщику, частично обеспечена, просрочена, заменена аналогом или снята. Без такой статусной карты ИИ будет говорить о закупке, но не будет понимать предмет закупочного управления.

Второй пример — ERP-объект. Пользователь спрашивает: «Можно ли по этому заказу запускать производство?» Если модель видит только документ «Заказ клиента», она может ответить формально: да, заказ есть, значит производство можно запускать. Но для предприятия этого недостаточно. Нужно понять состояние предмета: заказ согласован или нет, условия продажи подтверждены или нет, оплата требуется или нет, обеспечение материалов возможно или нет, есть ли ограничения по качеству, есть ли спецификация, есть ли маршрут, есть ли производственная мощность, есть ли запрет на изменение условий.

ERP-объект является важным носителем, но не равен бизнес-предмету. Документ «Заказ клиента» может быть одним из носителей предмета «клиентское обязательство» или «портфель отгрузки». Но сам предмет шире документа. Он включает условия исполнения, связь с обеспечением, связь с производством, финансовые ограничения, статус согласования, управленческий приоритет, риски и последствия. Если ИИ не различает документ и предмет, он будет рассуждать слишком прямо.

Третий пример — СМК-документ. Предприятие может загрузить в базу знаний процедуру контроля качества, форму протокола, инструкцию, регламент, чек-лист, акт несоответствия. ИИ прочитает эти документы и сможет пересказать их содержание. Но управленческий вопрос звучит иначе: какой предмет качества здесь управляется? Партия? Протокол контроля? Несоответствие? Разрешение на выпуск? Рекламация? Корректирующее действие? Доказательная запись?

Если предмет качества не задан, ИИ может смешать форму и событие. Он может считать, что наличие заполненного протокола означает пригодность продукции. Но протокол сам по себе может фиксировать как положительное решение, так и отклонение. Он может быть черновиком, может быть не согласован, может быть связан не с той партией, может не закрывать нормативное требование. СМК-документ без предметной связи не даёт полной управленческой правды.

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

Если предприятие хочет использовать ИИ в управлении, ему нужно дать ИИ не только текстовый контекст, но и граф знаний. Не в смысле красивой технологической моды, а в практическом смысле: нужно явно связать бизнес-предметы, их состояния, переходы, процессы, ERP-объекты, СМК-записи, документы, роли, показатели, нормативные основания и управленческие последствия.

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

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

Поэтому борьба с галлюцинациями в enterprise-контуре начинается не с новой версии модели и не с более длинного промпта. Она начинается с вопроса: какие предметы предприятия должны быть заданы, чтобы о них можно было рассуждать? Какие из них уже проявлены в ERP? Какие живут в документах? Какие существуют только в практике? Какие заданы нормативно, но не встроены в управление? Какие имеют состояния, а какие пока описаны только словами?

Эта постановка выводит нас к более глубокой развилке. Предмет для ИИ и для управленческого мышления должен быть не только назван. Он должен быть задан и дан. Задан — через типовую модель, методологию, нормативный слой, классификаторы, best practice. Дан — через фактическую деятельность конкретного предприятия, его исключения, боли, маршруты, роли, документы, ограничения и способы работы.

Именно здесь возникает необходимость философской опоры. Не ради отступления от темы, а ради точного различения. Нельзя рассуждать о предприятии, если предметы не заданы понятиями. Но нельзя построить живую модель предприятия, если предметы не даны самой практикой. Эту развилку удобно объяснить через Канта. К ней и переходит следующая глава. [3]

Глава 11. Кантовская развилка: задать предмет и дать предмет

На первый взгляд появление Канта в книге об ERP-системах, бизнес-предметах и интеллектуальном предприятии может показаться лишним. Кажется, что здесь достаточно практических слов: процессы, документы, справочники, регистры, показатели, граф знаний, LLM, доменная память. Зачем в эту прикладную область вводить философскую развилку?