Если попросить двух интеграторов прислать «список модулей 1С:ERP», списки могут заметно отличаться. В одном будут продажи, закупки, склад, производство и финансы. В другом к ним добавятся CRM, WMS, транспорт, проектное управление и отраслевые решения. Это не всегда означает, что кто-то ошибся: на рынке словом «модуль» называют разные сущности.
Для руководителя важнее другое. В типовой 1С:ERP уже есть крупные функциональные разделы и подсистемы. Часть возможностей внутри них включается и отключается настройками. Отдельно существуют решения, которые расширяют ERP, а некоторые задачи рациональнее оставить во внешней специализированной системе и связать интеграцией.
Поэтому функциональный периметр — это не максимальный список доступных функций. Это граница целевого решения: какие процессы, данные и управленческие решения должны жить в ERP, что нужно расширить, а что лучше оставить за её пределами.
Для руководителя важнее другое. В типовой 1С:ERP уже есть крупные функциональные разделы и подсистемы. Часть возможностей внутри них включается и отключается настройками. Отдельно существуют решения, которые расширяют ERP, а некоторые задачи рациональнее оставить во внешней специализированной системе и связать интеграцией.
Поэтому функциональный периметр — это не максимальный список доступных функций. Это граница целевого решения: какие процессы, данные и управленческие решения должны жить в ERP, что нужно расширить, а что лучше оставить за её пределами.
В этой статье вы узнаете
Какие модули и подсистемы входят в типовую 1С:ERP
Если говорить языком поискового запроса, под «модулями 1С:ERP» обычно имеют в виду крупные функциональные области самой типовой системы. В документации 1С они описаны как отдельные разделы и подсистемы, а не как единый закрытый перечень «модулей».
- Управление финансами и казначейство — заявки на расходование денег, платежи и контроль движения денежных средств.
- Бюджетирование — бюджеты, сценарии, план-факт и контроль исполнения.
- Продажи — заказы клиентов, условия продаж, взаиморасчёты и исполнение обязательств.
- CRM — сделки, этапы продаж и история взаимодействия с клиентами.
- Закупки — обеспечение потребностей, заказы поставщикам и контроль поставок.
- Планирование запасов — планы остатков и потребностей с учётом плановых приходов и расходов.
- Склад и запасы — остатки, резервирование, складские операции и доставка.
- Производство — потребности, ресурсные спецификации, этапы, материалы и выпуск.
- Затраты и себестоимость — расходы, незавершённое производство и расчёт фактической себестоимости.
- Ремонты — обслуживание и ремонт оборудования и других производственных активов.
- Персонал и зарплата — кадровые данные, рабочее время и расчёт зарплаты.
- Регламентированный учёт — бухгалтерский и налоговый учёт.
- Международный финансовый учёт — учёт и подготовка отчётности по МСФО.
- Аналитика и показатели — целевые показатели, отчётность и контроль результата.
Этот список показывает основные функциональные области типовой 1С:ERP. Для проектирования этого недостаточно. Дальше важнее понять две вещи: что относится к типовой системе, а что подключается отдельно, и как эти блоки складываются в целевой контур конкретной компании.
Модули, подсистемы и расширения 1С:ERP — в чём разница
Главная сложность здесь не техническая, а терминологическая. Официальная структура продукта и язык рынка не всегда совпадают: слово «модуль» используют и для встроенного функционального блока, и для отдельного решения, которое подключается к ERP.
Для практической работы я бы разделял три уровня.
Типовой функциональный контур. Это возможности самой конфигурации 1С:ERP: продажи, закупки, склад и доставка, производство, казначейство, бюджетирование, регламентированный учёт, персонал и другие области. Они работают внутри общего прикладного решения и используют общие данные.
Дополнительное решение, модуль или отраслевое расширение. Оно закрывает задачу, для которой типового механизма недостаточно или нужна более глубокая отраслевая логика. Такое решение может работать внутри экосистемы 1С и обмениваться данными с ERP.
Внешняя система. CRM, WMS, MES или другой специализированный продукт может остаться отдельной системой. Тогда важны не попытка «заменить всё ERP», а граница ответственности и обмен данными.
Дополнительное решение, модуль или отраслевое расширение. Оно закрывает задачу, для которой типового механизма недостаточно или нужна более глубокая отраслевая логика. Такое решение может работать внутри экосистемы 1С и обмениваться данными с ERP.
Внешняя система. CRM, WMS, MES или другой специализированный продукт может остаться отдельной системой. Тогда важны не попытка «заменить всё ERP», а граница ответственности и обмен данными.
Разница принципиальна. Если компания не использует часть типовой функциональности, это ещё не означает, что ей «не купили модуль». И наоборот: наличие широкого типового функционала не означает, что специализированная складская или производственная система автоматически становится лишней.
Как блоки 1С:ERP складываются в структуру системы
Функциональность 1С:ERP обширна, но читать её как длинный каталог мало полезно. Чтобы наметить периметр, удобнее сначала увидеть несколько крупных управленческих зон.
Коммерция и обеспечение. Сюда относятся работа с клиентами и условиями продаж, заказы, закупки, запасы, складские операции и доставка. Для руководителя это зона, где спрос клиента встречается с реальной возможностью компании его обеспечить.
Производство и активы. Производственный контур включает планирование и исполнение производства, работу с ресурсными спецификациями, этапами, материалами и выпуском. Рядом находятся задачи ремонтов и управления активами. Подробно производственный контур лучше рассматривать отдельно: здесь достаточно понимать его место в общей карте 1С:ERP.
Финансы и управленческий контроль. Казначейство, бюджетирование, затраты, себестоимость, финансовый результат и целевые показатели связывают операционные решения с деньгами и экономикой бизнеса.
Регламентированный учёт и персонал. Бухгалтерский и налоговый учёт, кадровые данные, рабочее время и расчёт зарплаты могут использовать факты, которые уже возникают в операционных процессах.
Общая информационная основа. НСИ, общие справочники, права, настройки, обмены и интеграции обеспечивают совместную работу остальных контуров. Этот слой редко обсуждают первым, хотя именно на нём быстро проявляются конфликты между «одной системой» и разными правилами подразделений.
Коммерция и обеспечение. Сюда относятся работа с клиентами и условиями продаж, заказы, закупки, запасы, складские операции и доставка. Для руководителя это зона, где спрос клиента встречается с реальной возможностью компании его обеспечить.
Производство и активы. Производственный контур включает планирование и исполнение производства, работу с ресурсными спецификациями, этапами, материалами и выпуском. Рядом находятся задачи ремонтов и управления активами. Подробно производственный контур лучше рассматривать отдельно: здесь достаточно понимать его место в общей карте 1С:ERP.
Финансы и управленческий контроль. Казначейство, бюджетирование, затраты, себестоимость, финансовый результат и целевые показатели связывают операционные решения с деньгами и экономикой бизнеса.
Регламентированный учёт и персонал. Бухгалтерский и налоговый учёт, кадровые данные, рабочее время и расчёт зарплаты могут использовать факты, которые уже возникают в операционных процессах.
Общая информационная основа. НСИ, общие справочники, права, настройки, обмены и интеграции обеспечивают совместную работу остальных контуров. Этот слой редко обсуждают первым, хотя именно на нём быстро проявляются конфликты между «одной системой» и разными правилами подразделений.
Эта карта нужна не для того, чтобы включить всё. Её задача — увидеть, где проходят связи. Например, производству нужны данные о потребности и материалах, финансовой службе — данные о будущих платежах и затратах, бухгалтерии — корректные первичные факты. Если каждый контур проектировать отдельно, формально «нужные модули» можно выбрать, а целостного решения всё равно не получится.
Что можно включать и отключать в типовой 1С:ERP
У 1С:ERP есть важный механизм, который часто теряется за разговором о модулях: функциональные опции. Они позволяют включать или отключать разные функциональные части прикладного решения настройками, без изменения самой конфигурации.
На практике один и тот же продукт у двух компаний может использоваться по-разному: набор включённых возможностей зависит от процессов и принятой модели работы.
Настройки находятся в разделе «НСИ и администрирование» и управляют доступностью отдельных возможностей внутри функциональных разделов. Для руководителя здесь важен не интерфейс настройки, а сам принцип: часть вопроса «какие модули нам нужны» на самом деле решается не покупкой нового продукта, а настройкой уже имеющейся типовой функциональности.
На практике один и тот же продукт у двух компаний может использоваться по-разному: набор включённых возможностей зависит от процессов и принятой модели работы.
Настройки находятся в разделе «НСИ и администрирование» и управляют доступностью отдельных возможностей внутри функциональных разделов. Для руководителя здесь важен не интерфейс настройки, а сам принцип: часть вопроса «какие модули нам нужны» на самом деле решается не покупкой нового продукта, а настройкой уже имеющейся типовой функциональности.
Отсюда полезное различие. «Мы не используем эту возможность типовой ERP» и «нам нужен отдельный модуль» — это разные ситуации. В первом случае может быть достаточно корректно настроить типовой контур. Во втором появляется дополнительный продукт, отдельная ответственность за его развитие и, как правило, новая интеграционная связь.
Когда типовой 1С:ERP недостаточно: что подключается отдельно
Сам факт, что в 1С:ERP есть CRM, склад, производство или бюджетирование, ещё не отвечает на вопрос, достаточно ли этого конкретной компании. У одного и того же названия функции могут быть очень разные требования.
Я бы рассматривал три базовых сценария.
Типового механизма достаточно. Он закрывает нужный сценарий и уровень детализации без отдельного продукта. В таком случае дополнительное решение добавит поддержку и интеграции, но не обязательно даст новую управленческую ценность.
Нужна специализированная глубина внутри экосистемы. Отрасль или процесс требует функций, которых нет в нужной глубине в типовой ERP. Тогда появляется отдельный модуль, отраслевое решение или расширение, которое дополняет основной контур.
Специализированная система остаётся отдельно. Сложный склад может жить в WMS, диспетчеризация производства — в MES, коммерческий процесс — в CRM. ERP при этом может оставаться основным контуром, где сходятся заказы, потребности, выпуски, затраты и финансовый результат. Здесь важно заранее определить, какая система является главной для каждого ключевого объекта и какой обмен нужен между ними.
Я бы рассматривал три базовых сценария.
Типового механизма достаточно. Он закрывает нужный сценарий и уровень детализации без отдельного продукта. В таком случае дополнительное решение добавит поддержку и интеграции, но не обязательно даст новую управленческую ценность.
Нужна специализированная глубина внутри экосистемы. Отрасль или процесс требует функций, которых нет в нужной глубине в типовой ERP. Тогда появляется отдельный модуль, отраслевое решение или расширение, которое дополняет основной контур.
Специализированная система остаётся отдельно. Сложный склад может жить в WMS, диспетчеризация производства — в MES, коммерческий процесс — в CRM. ERP при этом может оставаться основным контуром, где сходятся заказы, потребности, выпуски, затраты и финансовый результат. Здесь важно заранее определить, какая система является главной для каждого ключевого объекта и какой обмен нужен между ними.
Примеры решений, которые расширяют 1С:ERP
В официальной экосистеме 1С дополнительная глубина может появляться в разных классах решений:
- CRM — «1С:CRM. Модуль для 1С:ERP и 1С:КА»: более глубокое управление взаимодействиями с клиентами и связанными процессами.
- MDM — «1С:MDM Управление мастер-данными КОРП»: централизованное ведение, унификация и контроль качества мастер-данных.
- MES — «1С:MES Оперативное управление производством»: оперативное планирование, диспетчеризация и контроль выполнения производства.
- PLM — «1С:PLM Управление жизненным циклом»: управление жизненным циклом изделия и конструкторско-технологической подготовкой.
- PM — «1С:PM Управление проектами. Модуль для 1С:ERP и 1С:КА»: управление проектами, сроками, содержанием и проектной деятельностью.
- WMS — «1С:WMS Логистика. Управление складом»: специализированное управление технологическими процессами склада в реальном времени.
- Автотранспорт — «1С:Управление автотранспортом. Модуль для 1С:ERP»: управление и учёт автотранспорта и транспортных подразделений.
- ТОИР / надёжность — «1С:ТОИР Управление ремонтами и обслуживанием оборудования» и «1С:RCM Управление надежностью»: обслуживание активов, ремонты и управление надёжностью.
- Отраслевой модуль — «1С:Молокозавод. Модуль для 1С:ERP и 1С:КА»: отраслевые процессы управления и учёта молочного производства.
Это не список «обязательных модулей» и не рейтинг решений. Он показывает другой архитектурный уровень: типовая ERP остаётся основой, а дополнительное решение появляется там, где нужна специализированная глубина, отдельный класс задач или отраслевой сценарий.
CRM — показательный пример
В типовой 1С:ERP уже есть управление взаимоотношениями с клиентами: сделки, этапы продаж, история взаимодействий и анализ процесса продаж. Одновременно существует отдельный продукт «1С:CRM. Модуль для 1С:ERP и 1С:КА», который можно интегрировать в единую информационную систему.
Поэтому запрос «1С:ERP модуль CRM» нельзя сводить к ответу «CRM либо есть, либо нет». Сначала нужно проверить, хватает ли типовой CRM-функциональности под реальные сценарии компании. Отдельный CRM-модуль имеет смысл обсуждать только там, где действительно нужна дополнительная глубина.
Поэтому запрос «1С:ERP модуль CRM» нельзя сводить к ответу «CRM либо есть, либо нет». Сначала нужно проверить, хватает ли типовой CRM-функциональности под реальные сценарии компании. Отдельный CRM-модуль имеет смысл обсуждать только там, где действительно нужна дополнительная глубина.
Именно здесь проходит граница решения. Попытка любой ценой уместить всё в одной базе может быть такой же ошибкой, как и бесконтрольное размножение отдельных систем. Задача не в минимальном числе программ, а в понятной ответственности за процессы, данные и обмен между системами.
Как определить функциональный периметр
Я обычно начинаю не с вопроса «какие модули поставить», а с требований и ограничений. Название продукта само по себе не определяет задачу. Для черновой карты периметра достаточно последовательно ответить на шесть вопросов.
1. Какой бизнес-процесс и какое решение мы хотим изменить?
Не «нужен модуль закупок», а, например, «служба снабжения должна видеть подтверждённую потребность и формировать обеспечение с учётом сроков». Чем точнее управленческая задача, тем меньше соблазн выбирать функционал по названию.
2. Какие данные должны стать общими?
Номенклатура, контрагенты, заказы, спецификации, остатки, статьи затрат, структура подразделений, показатели. Если один объект нужен нескольким процессам, нужно заранее определить, где он создаётся и кто отвечает за его качество.
3. Где достаточно типового механизма, а где нужна специализированная глубина?
Типовая ERP может закрывать процесс полностью, частично или только на уровне обмена итоговыми данными. Это нужно проверять на реальном сценарии, а не по фразе «функция есть».
4. Какая система должна быть главной для ключевых объектов?
Если заказ создаётся в CRM, остаток считается в WMS, производство исполняется через MES, а финансовый результат собирается в ERP, необходимо явно определить главную систему-источник для каждого объекта и правила синхронизации.
5. Какие интеграции неизбежны?
Интеграция — не техническая деталь «на потом». Она определяет, насколько быстро данные переходят между процессами, где возможны расхождения и кто будет отвечать за сбой обмена.
6. Что не нужно включать в целевой контур по умолчанию?
Это один из самых полезных вопросов. В старой системе может быть много доработок, отчётов и исторических правил. Сам факт их существования не делает их обязательными требованиями новой архитектуры.
Если на эти вопросы нет ответов, обсуждать конкретный список модулей рано. Можно получить красивую таблицу функций, но не функциональный периметр.
Если на эти вопросы нет ответов, обсуждать конкретный список модулей рано. Можно получить красивую таблицу функций, но не функциональный периметр.
Почему «всё в одной ERP» не всегда лучший периметр
В одном из наших проектов компания переходила с сильно доработанной 1С:УПП на 1С:ERP. Задача включала складские и производственные процессы, управленческий учёт и обмен с отдельной бухгалтерской базой.
Целевую схему не строили по принципу «теперь всё должно жить только в ERP». Компания перешла на 1С:ERP; в складском контуре использовали адресное хранение и учёт сроков годности. При этом ИТАН сохранили в связке с ERP, а обмен с бухгалтерской базой оставили.
Целевую схему не строили по принципу «теперь всё должно жить только в ERP». Компания перешла на 1С:ERP; в складском контуре использовали адресное хранение и учёт сроков годности. При этом ИТАН сохранили в связке с ERP, а обмен с бухгалтерской базой оставили.
В этом примере важен не сам переход с УПП и не эффект проекта. Важна архитектурная логика: типовой ERP, дополнительное решение и отдельная система могут работать вместе, если у каждого понятна роль. Периметр определяется задачами и данными, а не идеей, что одна коробка обязана заменить всё.
Что зафиксировать перед оценкой проекта
Ответы на шесть вопросов выше удобно свести в одну короткую карту по каждому ключевому процессу:
После такой карты список модулей перестаёт быть абстрактным. Видно, где типовой функционал уже достаточен, где нужна дополнительная глубина и где отдельная система остаётся рациональной частью архитектуры.
Вместо вывода
Вопрос «какие модули есть в 1С:ERP?» полезен как начало разговора, но не как способ определить состав решения. Для проекта важнее понять, что уже закрывает типовая ERP, где требуется дополнительная глубина и какие специализированные системы должны остаться рядом.
Мой критерий простой: сначала требования и ограничения, потом название продукта и его состав. Если процесс, данные, владелец и ожидаемый результат не определены, выбирать модули рано.
Если сначала нужно понять сам продукт и кому он подходит, начните с обзора «1С:ERP: что это за программа, что умеет и кому подходит». Для производственного контура отдельный следующий уровень — материал о производстве в 1С:ERP, а для глубокого производственного планирования — отдельная статья о планировании. Когда функциональный периметр уже понятен и вопрос переходит к организации проекта, следующий шаг — оценка внедрения 1С:ERP.
Мой критерий простой: сначала требования и ограничения, потом название продукта и его состав. Если процесс, данные, владелец и ожидаемый результат не определены, выбирать модули рано.
Если сначала нужно понять сам продукт и кому он подходит, начните с обзора «1С:ERP: что это за программа, что умеет и кому подходит». Для производственного контура отдельный следующий уровень — материал о производстве в 1С:ERP, а для глубокого производственного планирования — отдельная статья о планировании. Когда функциональный периметр уже понятен и вопрос переходит к организации проекта, следующий шаг — оценка внедрения 1С:ERP.
