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

Во-вторых, процессный подход показывает роли. Становится видно, где действует менеджер, где кладовщик, где плановик, где бухгалтер, где технолог, где ОТК, где руководитель, где экономист, где специалист по качеству. Это важно, потому что ERP-проект без ролевой структуры быстро превращается в набор абстрактных документов, которые «кто-то должен создать».

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

В-четвёртых, процессный подход позволяет увидеть точки контроля. Если процесс описан, можно спросить: где проверяется правильность данных? Где согласование? Где контроль качества? Где подтверждение факта? Где ручная операция? Где риск задержки? Где точка передачи между подразделениями? Где создаётся доказательная запись?

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

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

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

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

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

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

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

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

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

Если предмет не назван, процесс начинает притворяться полным. В тексте появляются слова «оформить», «проверить», «согласовать», «передать», «создать», «провести», «закрыть», но остаётся неясно, что именно изменилось в управлении. Документ создан — но предмет перешёл в новое состояние или нет? Согласование выполнено — но обязательство возникло или только подготовлено? Отчёт сформирован — но решение принято или только появились данные для решения?

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

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

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

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

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

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

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

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

Если handoff-точка не описана предметно, возникает типовой разрыв: один контур считает, что свою работу выполнил, а следующий контур не может работать. Закупка говорит: «Мы заказали». Склад говорит: «У нас нет доступного остатка». Производство говорит: «Материала нет». Бухгалтерия говорит: «Документы не отражены». Руководитель говорит: «Почему заказ стоит?» Формально действия выполнены, но предмет не перешёл в нужное состояние.

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

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

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

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

Второй пример — производство. Формально процесс можно описать так: «Создать производственный заказ, обеспечить материалами, выполнить операции, выпустить продукцию, передать на склад, закрыть заказ». Это правильный процедурный каркас. Но предметно здесь возникает более сложная картина.

Что является главным предметом процесса? Производственный заказ? Производственная партия? Выпуск? НЗП? Производственное обязательство перед продажами? Ответ зависит от уровня описания. На одном уровне главным предметом может быть производственная программа. На другом — производственный заказ. На третьем — партия продукции. На четвёртом — состояние НЗП. На пятом — готовность изделия к передаче на склад или контролю качества.

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

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

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

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

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

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

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

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

Эта формула важна для всей книги:

процесс — это маршрут изменения состояния бизнес-предмета.

Не просто маршрут действий. Не просто последовательность документов. Не просто регламент. Не просто схема согласования. А именно маршрут, по которому предмет предприятия проходит от одного управленчески значимого состояния к другому.

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

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

Глава 14. ERP-объект не равен бизнес-предмету

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

На этом этапе возникает вторая типовая ошибка: бизнес-предмет начинают отождествлять с ERP-объектом.

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

Но это слишком прямое мышление. Оно удобно для обучения интерфейсу, но опасно для построения предметной модели предприятия.

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

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

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

Это приводит к нескольким искажениям.

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

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

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

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

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

Поэтому формула главы звучит жёстко:

ERP-объект не равен бизнес-предмету.

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

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

ERP-объект является носителем, следом, отражением, технической реализацией или точкой фиксации бизнес-предмета.

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

Рассмотрим первый важный случай: один бизнес-предмет может быть реализован несколькими ERP-объектами.

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

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

Другой пример — «партия продукции». В ERP партия может проявляться через выпуск продукции, складской остаток, серию, характеристику, назначение, документ передачи, складской ордер, регистр себестоимости, документ контроля качества, решение о пригодности, отчёт по остаткам, отчёт по движениям, документ реализации, рекламацию. Если принять за партию только складской остаток, потеряется качество. Если только выпуск — потеряется движение. Если только себестоимость — потеряется прослеживаемость. Если только серия — потеряется экономическая сторона.

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

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

Теперь рассмотрим обратный случай: один ERP-объект может обслуживать несколько бизнес-предметов.

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