ERP-Лабиринты. Где выход?

ERP-Лабиринты. Где выход?

Кирилл Ледовский

© Кирилл Ледовский, 2026

ISBN 978-5-0071-0464-7

Создано в интеллектуальной издательской системе Ridero

Введение. Как из предметных областей собирается модель предприятия

Первый том «Мы теряем контроль над сложной 1С: ERP. Что делать?» показывал систему с другой стороны: как предприятие постепенно теряет объяснимость собственных решений, связей и изменений. Здесь вопрос становится предметнее. Во втором томе «ERP-Лабиринты. Где выход?» нас интересует не то, почему ERP превратилась в лабиринт вообще, а чем именно предприятие управляет внутри каждой области и почему привычный документ, экран или большая процессная схема не заменяют предметную архитектуру.

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

Логика проектной работы в этих главах одна и та же. Сначала определяется граница предметной области и различаются бизнес-предметы, которые внутри неё действительно живут. Затем для предметов фиксируются состояния, события и процессные роли; из изменений предметов раскрываются самостоятельные процессы и межпроцессные передачи. Когда такие области соединяются между собой, становится видна уже не отдельная схема отдела, а связанная модель предприятия. Рабочая цепочка этой книги проста: предметные области → бизнес-предметы → состояния и события → процессы и передачи → единая бизнес-модель предприятия.

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

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

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

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

Часть I. Когда привычный объект перестаёт быть всей предметной областью

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

Глава 1. ERP-лабиринты: автоматизация ремонтов — заявка ещё не процесс

Почему аккуратная BPMN-схема не раскрывает предметную архитектуру ТОиР

Задача, которую получает аналитик, обычно звучит просто: описать процесс ремонта оборудования и показать, как он должен поддерживаться в 1С: ERP. Аналитик проводит интервью, определяет участников, собирает формы документов и рисует понятную BPMN-схему. В ней есть инициатор, ремонтная служба, руководитель, склад, несколько развилок, ожидание запасной части, выполнение работ и закрытие заявки.

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

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

Первая попытка: обработать заявку от начала до конца

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

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

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

BPMN здесь ни в чём не виновата

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

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

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

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

Вторая попытка: добавить в схему всё предприятие

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

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

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

Она стала больше. Но не стала яснее.

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

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

Попытка обслуживать прибор по его тени

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

Тень не является ложью. Она действительно создана прибором. По ней можно понять общий силуэт и приблизительное положение объекта.

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

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

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

Предмет-драйвер не существует в одиночестве

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

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

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

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

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

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

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

Именно этого не видно, когда весь предметный мир сворачивается в единую «заявку».

Зачем предмету нужен таксон

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

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

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

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

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

ТОиР не является островом внутри предприятия

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

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

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

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

Выполненные работы создают учётный след. Материалы списываются, труд и услуги образуют затраты, возникает экономическое событие, влияющее на стоимость владения оборудованием и результат периода. Эти предметы связаны с ремонтом, но не превращаются из-за этого в его внутренние статусы.

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

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

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

Тринадцать процессов вместо одной заявки

В предметно-процессной модели ТОиР выделены 13 бизнес-предметов и 13 бизнес-процессов. Процессный слой раскрыт через 43 процедуры и 86 операций.

Эти числа нужны не для демонстрации размера таблицы. Они показывают разницу между плоской проекцией и объёмной архитектурой.

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

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

Один процесс в правильном окружении

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

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

Каждый из этих предметов имеет собственное происхождение. План не является дефектом. Диагноз не является решением. Факт повреждения не является заданием. Но каждый из них способен стать основанием для возникновения потребности.

Предметом-драйвером рассматриваемого процесса является потребность в техническом обслуживании или ремонте.

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

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

Процесс заканчивается здесь.

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

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

Почему один документ 1С не решает предметную задачу

Можно возразить: если все сведения удобно хранить в одном документе 1С, почему бы не считать его главным предметом?

Потому что прикладной объект отвечает на вопрос, где и как информация зафиксирована, а бизнес-предмет — чем предприятие управляет по смыслу.

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

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

Именно поэтому пользователи позднее говорят, что 1С: ERP «не додумана» или «не умеет правильно вести ремонт». Во многих случаях проблема находится не в отсутствии экранной формы. Проектная команда не определила предметный мир, а затем ожидала, что документы и статусы программы сами восстановят его.

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

Только после этого можно определить, где достаточно стандартной логики 1С: ERP, где требуется настройка, а где необходимо расширение прикладного решения.

Это уже следующий уровень работы. Его нельзя получить простым увеличением BPMN-схемы.

Почему возникает ERP-лабиринт