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

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

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

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

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

Так возникает главная развилка главы: предмет должен быть задан и дан.

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

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

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

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

Задать предмет обычно быстрее и дешевле, чем извлечь его из предприятия с нуля. Именно поэтому типовые модели, методики и best practice так ценны. Они не заставляют проект начинать с пустого листа. Они дают профессиональный язык. Они позволяют сразу спросить: где у вас возникает потребность? Как вы управляете резервом? Как фиксируете несоответствие? Кто принимает решение по партии? Где замыкается обязательство перед клиентом?

Но предмет нужно не только задать. Его нужно дать.

Для будущего инициирующего ядра это различение принципиально. Задать предмет — значит ввести его как смысловую единицу: назвать, ограничить, отличить от других предметов, определить его состояния и признаки. Дать предмет — значит связать его с носителями, фактами, документами, ERP-объектами, СМК-записями, источниками и событиями, через которые он становится проверяемым.

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

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

Например, предприятие может не говорить: «У нас плохо управляется предмет „дефицитный остаток“». Оно говорит иначе: «На складе что-то есть, но производство всё равно не может стартовать». Или: «Закупка говорит, что заказано, производство говорит, что не обеспечено». Или: «В отчёте остаток есть, а в цеху говорят, что материала нет». За этими фразами нужно увидеть предмет: обеспеченность, дефицит, резерв, доступность, назначение, потребность, замена, срок поступления.

Другой пример — предприятие может не называть предмет «доказательная запись качества». Оно говорит: «У нас протоколы есть, но при проверке их трудно найти». Или: «ОТК проверяет, но в ERP это никак не видно». Или: «Продукция отгружена, а решение по отклонению лежит в письме». Здесь предмет даётся через разрыв между процедурой, документом, ERP-объектом и доказательством.

Третий пример — предприятие может не осознавать предмет «управленческое обязательство по сроку». Оно говорит: «Менеджер обещал клиенту, производство не знало, закупка не успела, потом всё срочно переносили». Формально есть заказ, письма, план, дата отгрузки. Но предметом является не отдельный документ, а обязательство, которое должно пройти через продажи, обеспечение, производство, склад, отгрузку и финансы.

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

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

Поэтому нельзя брать только типовую модель. Типовая модель задаёт предметы, но не знает конкретной жизни предприятия. Она не знает, где сотрудники обходят систему, где документ создаётся поздно, где Excel сильнее ERP, где старый процесс сохраняется после внедрения, где руководитель принимает решение вне маршрута, где регламент написан, но не работает. Если ограничиться типовой моделью, можно получить красивую архитектуру без реальной силы. [12]

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

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

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

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

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

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

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

Глава 12. Авторский опыт: почему консультанты видят кнопки, но не видят предметы

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

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

Именно отсюда появляется феномен «волшебных кнопочек». Пользователь спрашивает: какую кнопку нажать, чтобы запустить производство? Какой документ сделать, чтобы списать материал? Где поставить флаг, чтобы заработал учёт серий? Какой отчёт открыть, чтобы увидеть остатки? Где включить адресный склад? Как провести реализацию? Как закрыть месяц?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Такой взгляд меняет практику. Аналитик перестаёт спрашивать только «какой документ создаётся?» и начинает спрашивать: какой предмет изменил состояние, где это изменение зафиксировано, кто владелец записи, какой источник подтверждает факт, какие последствия возникли и какой следующий процесс должен получить этот предмет. С этого момента предметно-ориентированное мышление становится не теорией, а подготовкой к сборке ядра.

Часть III «Почему процессов, документов, ERP-объектов и BPM/BPA-моделей недостаточно»

К привычным опорам предприятия — процессам, документам, ERP-объектам, СМК и KPI — нужно добавить ещё одну важную категорию: средства бизнес-моделирования и BPM/BPA-системы. Они полезны, потому что помогают фиксировать процессы, роли, документы, регламенты, организационную структуру, показатели и процессные связи. Но они также имеют границу.

Эта книга не критикует какой-либо конкретный продукт или конкретного разработчика. Речь идёт о классе инструментов. BPM/BPA-система может хорошо поддерживать процессное описание, но сама по себе не гарантирует наличие самостоятельного предметного слоя предприятия. Можно иметь аккуратный процессный репозиторий и всё равно не знать, какой бизнес-предмет является предметом управления, какие у него состояния, где его носители и как он связан с цифровой нитью.

Поэтому вопрос этой части шире: почему никакой отдельный слой — процесс, документ, ERP-объект, СМК-форма, KPI или BPM/BPA-модель — не заменяет предметный мир. Все эти слои нужны, но они должны быть связаны в инициирующем ядре.

Глава 13. Процесс без предмета — процедурная оболочка

Часть II закончилась на простой, но неприятной мысли: предприятие может иметь ERP, регламенты, процессы, отчёты, KPI, СМК и даже корпоративного ИИ, но при этом не иметь явно заданного предметного мира. В таком случае ИИ начинает достраивать связи сам, консультант видит кнопки, пользователь видит документы, руководитель видит отчёты, но устойчивого управленческого рассуждения не возникает.

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

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

Процессный подход даёт несколько сильных вещей.

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