Как мы остановились на процессном подходе — и почему предметный слой пришлось вынести отдельно
У концепций есть неприятное свойство: в финальную версию попадает не всё, что хотелось.
Когда в 2025 году мы работали над концепцией прикладного решения «1С:ERP Управление предприятием», а в 2026 году она была вынесена в учебный курс УЦ №1 фирмы «1С», у нас довольно быстро возникла простая развилка.
Можно объяснять ERP через подсистемы, документы и кнопки. Это привычно, понятно, методически безопасно.
Можно объяснять ERP через процессы. Это уже интереснее: система перестаёт быть набором экранов и начинает выглядеть как деятельность предприятия.
А можно пойти ещё глубже — объяснять ERP через предметы управления: потребности, партии, запасы, обязательства, НЗП, выпуск, себестоимость, рекламации, доказательные записи, лимиты, отклонения.
Вот вокруг этого третьего слоя мы и ходили кругами.
И да, были версии, где предметный подход пытались вставить прямо в концепцию. Были схемы, заметки, куски будущих объяснений. Были споры — не в смысле академических дискуссий, а обычные рабочие разговоры: «а если вот здесь сразу показать предмет?», «а если объяснить, что ERP-объект не равен бизнес-предмету?», «а если дать хотя бы вводный слой по управленческому учёту через объекты?»
Потом стало понятно: не надо.
Не потому что предметный слой неважен. Наоборот, как раз потому что он слишком важен и слишком тяжёлый для входной концепции.
Итоговая запись концепции — около 50 часов видео. Это уже большой объём. Но исходных наработок было больше. Просто у учебного формата есть предел. Если человек только входит в 1С:ERP, нельзя сразу навалить на него подсистемы, процессы, предметы, графы знаний, LLM, СМК, управленческий учёт, цифровой двойник и интеллектуальное предприятие.
Он не войдёт в систему. Он утонет.
Поэтому мы приняли довольно трезвое решение: в концепцию пойдёт процессный подход.
Тем более процессы у нас были не придуманы «под курс». Это была типовая процессная модель для дискретного предприятия, которую мы много лет использовали, проверяли, гоняли через проекты, переделывали, уточняли и в целом уже понимали, где она работает. Её и имело смысл провести через концепцию.
Процессная концепция получилась сквозной. И это, на мой взгляд, правильно. А предметно-ориентированную линию мы решили вынести отдельно.
Почему не кнопки
С кнопок начинать проще всего. Открываем подсистему. Создаём документ. Заполняем реквизиты. Проводим. Формируем отчёт. Проверяем результат. Это нормальный вход в систему. Без него никак. Человеку надо знать, где что находится и что делать руками.
Но если ERP объяснять только так, она превращается в большой интерфейс. У пользователя возникает ощущение: система — это набор документов, справочников, отчётов и кнопок. А дальше начинается знакомая проблема: документ создали, отчёт сформировали, но управленческий смысл действия не всегда понятен.
Что именно изменилось в деятельности предприятия? Какой предмет перешёл в новое состояние? Какой риск закрыли? Какое обязательство возникло? Что стало основанием для следующего действия?
Кнопка на это не отвечает. Документ тоже не всегда отвечает. Он фиксирует действие, но не объясняет всю управленческую логику. Поэтому процессный подход оказался для концепции удачным компромиссом. Он не перегружает человека онтологией, но уже вытаскивает его из интерфейса в деятельность.
Не «создайте заказ клиента», а «посмотрите, как предприятие принимает и исполняет обязательство перед клиентом».
Не «оформите поступление», а «посмотрите, как потребность превращается в обеспеченный ресурс».
Не «сформируйте отчёт», а «посмотрите, какой результат получила цепочка действий».
Это уже другой разговор.
Почему процессы сработали
Процессы хороши тем, что они возвращают в ERP живое предприятие.
Когда смотришь на продажи через документы, видишь заказ клиента, реализацию, оплату, отчёты. Когда смотришь процессно, видишь цепочку: запрос клиента, обязательство, проверка возможности исполнения, резерв, производство или отгрузка, выручка, дебиторка, деньги.
Когда смотришь на закупки через документы, видишь заявку, заказ поставщику, поступление, оплату. Когда смотришь процессно, видишь потребность, обеспечение, поставщика, срок, качество, склад, обязательство и влияние на производство.
Когда смотришь на производство через документы, видишь заказ на производство, этапы, списание, выпуск. Когда смотришь процессно, видишь потребность, обеспеченность, НЗП, выпуск, качество, себестоимость и дальнейшую отгрузку.
Для учебной концепции это сильный уровень. Он достаточно глубокий, чтобы человек перестал воспринимать ERP как набор форм. И при этом ещё не настолько тяжёлый, чтобы превращать курс в онтологию предприятия.
Поэтому мы на этом уровне и остановились.
Сейчас это выглядит очевидным. Но в процессе подготовки это не было таким прямым решением. Несколько раз хотелось пойти дальше.
Особенно когда попадались места, где процесс сам просил предметного объяснения. Например, обеспеченность производства. Это не просто процесс закупки и не просто остатки на складе. Там сразу всплывают потребности, резервы, партии, сроки, качество, замены, дефициты. И рука сама тянется сказать: «Стоп, здесь надо вводить бизнес-предмет». Но если вводить его в одном месте, то надо вводить везде. А это уже другая концепция.
Где процесс начинает не справляться
У процесса есть граница. Он показывает маршрут. Но не всегда показывает, что именно проходит через маршрут.
Например, есть закупка. Процесс понятен: выявили потребность, согласовали, заказали, получили, проверили, положили на склад, отразили обязательство, оплатили.
Но чем именно предприятие управляет?
Потребностью? Заказом? Материалом? Партией? Качеством партии? Обязательством поставщику? Обеспеченностью производства?
Ответ зависит от того, с какой стороны смотреть.
Для снабжения важна потребность и её обеспечение. Для склада — запас. Для качества — партия и её статус. Для финансов — обязательство и платёж. Для производства — доступность ресурса под конкретный заказ.
И вот тут процессной схемы уже мало. Она показывает движение, но не показывает весь предметный смысл. На схеме всё может быть красиво, но управленческие вопросы остаются.
Тогда появляется простая формула: процесс — это маршрут изменения состояния бизнес-предмета. Я не стал бы вставлять эту формулу в самый первый входной курс. Для неподготовленного слушателя она тяжеловата. Ему ещё надо понять систему, её контуры и процессы. Но для проектной работы без этой формулы уже сложно.
Потому что иначе мы рисуем процессы, но не всегда понимаем, чем предприятие реально управляет.
Бизнес-предметы: вот это и не вошло
Бизнес-предмет — это не документ и не отчёт. Это то, что предприятие различает как управляемую сущность.
Запас. Партия. Потребность. Обязательство. НЗП. Выпуск. Рекламация. Лимит. Дебиторская задолженность. Доказательная запись качества. План-фактовое отклонение. У такого предмета есть состояние. Он возникает, меняется, передаётся, проверяется, принимается, отклоняется, закрывается. И если предприятие не различает предмет, оно не может устойчиво им управлять.
Можно сто раз сказать «у нас проблема со складом». Но что именно не так? Остаток? Доступность? Резерв? Партии? Качество? Адресное хранение? Неликвиды? Ошибка учёта? Дефицит под производство? Пока это всё называется одним словом «склад», управление размыто.
То же с финансами. «Прибыль есть, денег нет» — прекрасная фраза, которую все слышали. Но дальше надо разбирать предметы: дебиторка, запасы, НЗП, авансы, кредиторка, график платежей, кассовые разрывы, финансовый цикл.
Именно предметы делают управление различимым. Мы пробовали вставлять этот слой в концепцию. Но быстро стало понятно, что он потянет за собой слишком много всего: состояния, переходы, ERP-носители, KPI, СМК, управленческий учёт, LLM, граф знаний. Концепция стала бы не процессной, а предметно-ориентированной. А это уже отдельный курс. И, видимо, рано или поздно его действительно придётся записывать.
Потому что будущее, как мне кажется, именно за предметно-ориентированным подходом. Не потому что это красивое слово, а потому что без него невозможно построить интеллектуальное предприятие. ИИ не может надёжно рассуждать о предприятии, если предприятие само не различило свои предметы.
ERP-объект — это ещё не предмет
Самая частая ловушка в ERP-проектах — принять объект системы за предмет управления.
Документ «Заказ клиента» есть. Значит, кажется, что он и есть предмет. Но за ним могут стоять разные вещи: клиентское обязательство, резерв, производственная потребность, будущая выручка, дебиторская задолженность.
Документ «Поступление» есть. Но за ним живут партия, запас, обязательство поставщику, качество, стоимость, дальнейшее обеспечение производства.
Отчёт по остаткам есть. Но отчёт — не запас. Он только показывает его проекцию. Статус документа есть. Но статус документа не всегда равен состоянию бизнеса.
Для опытного консультанта это, возможно, очевидно. Но в методике это надо проговаривать. Особенно теперь, когда рядом с ERP появляется ИИ. Человек ещё может держать смысл в голове. LLM — нет. Если не сказать ей, что является предметом, а что только носителем, она будет достраивать сама. И иногда очень убедительно.
Объектно-ориентированный учёт тоже просился внутрь
Был ещё один слой, который очень хотелось вставить, — объектно-ориентированный управленческий учёт. Точнее, даже не «хотелось», а он сам постоянно лез в текст. Как только начинаешь объяснять ERP через деятельность, сразу появляются вопросы учёта: что является объектом учёта, что объектом управления, какие аналитики нужны, где факт, где методологическое правило, где источник данных, как собирается себестоимость, как появляется финансовый результат.
Например, производственная себестоимость. Можно показать документы и отчёты. Но по-настоящему там надо говорить о прямых материалах, НЗП, выпуске, общепроизводственных расходах, браке, отходах, распределениях и правилах закрытия.
Продажи — это не только реализация. Это выручка, скидки, возвраты, дебиторка, деньги, себестоимость продаж, маржа.
Бюджетирование — это не просто формы. Это плановые объекты, сценарии, версии, драйверы, правила расчёта, сопоставимость факта и плана.
Лимиты БДР и БДДС — вообще отдельная история. Один лимит контролирует право нести расход, другой — право оплатить обязательство. Если это смешать, управленческий контроль становится мутным.
Всё это очень интересно. Но для концепции — перегруз.
Поэтому управленческий учёт тоже пришлось оставить как отдельную ветку. Он связан с предметным подходом напрямую, но требует своего учебного маршрута. И именно поэтому по этой линии отдельно готовятся мини-курсы Галины по управленческому учёту в 1С:ERP.
В статье я не буду уводить туда подробно. Просто фиксирую: это ещё один пласт, который не вошёл не потому, что он не нужен, а потому что в общей концепции его невозможно раскрыть честно и коротко.
Почему сейчас без предметов уже трудно говорить про ИИ
Если бы вопрос был только в методике внедрения, можно было бы отложить эту тему ещё на несколько лет. Но ИИ всё ускорил. LLM хорошо работает с текстом. Она умеет объяснять, обобщать, формулировать, собирать черновики, помогать с отчётами. Но она не является памятью предприятия.
Если дать ей набор документов, она не получит автоматически предметную модель. Она увидит фрагменты. Где-то документ, где-то регламент, где-то отчёт, где-то описание процесса. А связи между предметами начнёт достраивать сама.
Иногда это выглядит прилично. В этом и проблема. Плохой ответ легко заметить. А вот уверенный, гладкий, почти правильный ответ — опаснее. Он может чуть-чуть смешать уровни: принять отчёт за источник истины, документ за предмет, статус за бизнес-состояние, общий совет за применимое управленческое действие.
Поэтому я всё чаще возвращаюсь к одной мысли: LLM должна быть не источником истины, а интерфейсом к графу знаний. Память предприятия должна жить в проверяемой структуре: предметы, связи, источники, статусы, версии, факты, действия. А LLM должна помогать человеку эту структуру читать. Именно здесь предметно-ориентированный подход становится не философией, а инженерным условием.
Почему мы всё-таки решили этим поделиться
Сейчас, оглядываясь назад, я думаю, что решение остановить концепцию на процессном подходе было правильным. Концепция получилась сквозной. Она не развалилась на десяток глубоких боковых тем. Человек может пройти её и увидеть 1С:ERP как систему деятельности, а не как свалку функций. Это уже много. Но предметный слой всё равно остался. Он не исчез. Он просто не вошёл в этот формат.
И чем больше вокруг ERP появляется разговоров про ИИ, графы знаний, цифровые двойники и интеллектуальное предприятие, тем очевиднее становится: этот слой надо выносить отдельно.
Поэтому я и подготовил небольшую бесплатную методичку на 38 страниц о том, что не вошло в концепцию. Не как замену концепции. Не как критику. И не как «вот теперь настоящая версия». Скорее как рабочие заметки, приведённые в порядок. Если вам интересны бизнес-предметы, различие между ERP-объектом и предметом, граф знаний, LLM как интерфейс и предметно-ориентированный подход к 1С:ERP, можете почитать.
Возможно, что-то из этого пригодится в вашей работе.
Вместо вывода
Я бы сформулировал так. Кнопочный подход нужен, чтобы войти в систему. Процессный подход нужен, чтобы увидеть деятельность предприятия. Предметный подход нужен, чтобы понять, чем предприятие управляет.
В концепцию 1С:ERP вошёл второй уровень — процессный. И это было правильное решение для учебного курса.
Третий уровень — предметный — пришлось оставить за рамками. Но, похоже, именно к нему всё равно придётся возвращаться. Потому что интеллектуальное предприятие, к которому все движется, не построить на одних документах, отчётах и красивых ответах LLM. Ему нужны предметы.