О чём эта статья
Это статья из продуктовой подборки ERP-Мастер о том, как связать внешние инженерные системы с 1С:ERP так, чтобы данные из конструкторско-технологической среды не просто «загрузились», а стали пригодными для производства, закупок, склада, планирования, кооперации и расчёта себестоимости.Речь не о выборе конкретной PDM/PLM/CAD-системы. На предприятиях могут использоваться Лоцман, 1С:PDM / управление инженерными данными, 1С:APPIUS, Intermech, Компас, CAD-системы, PLM-системы, отраслевые решения для механообработки, электрических схем, технологической подготовки производства и другие инструменты. ERP-Мастер работает не вместо этих систем, а на границе между инженерной системой и 1С:ERP.
Вопрос подписчика
«У нас есть инженерная система: PDM/PLM/CAD, Лоцман, 1С:PDM, Intermech, Компас или другая система подготовки инженерных данных. В ней живёт состав изделия, маршруты, техпроцессы и изменения. Но 1С:ERP нужна для производства, закупок, склада и себестоимости. Можно ли просто настроить обмен, чтобы всё само загружалось в ERP?»
Ответ ERP-Мастер
Связывать инженерную систему с 1С:ERP можно и нужно. Но это не задача «перенести дерево изделия». Интеграция инженерной системы и 1С:ERP — это перевод инженерной структуры изделия в производственно-учётную структуру ERP.Сначала нужно понять, какая структура нужна самой 1С:ERP: номенклатура, виды номенклатуры, ресурсные спецификации, материалы, полуфабрикаты, этапы, операции, рабочие центры, подразделения, нормы, статьи калькуляции, кооперация, правила себестоимости. И только потом задавать вопрос: какие данные для этой структуры приходят из инженерной системы, какие дополняются на стороне ERP, а каких у конструкторов и технологов вообще не может быть по природе их работы.
Где эта статья находится в подборке ERP-Мастер
Эта статья продолжает несколько материалов продуктовой линейки ERP-Мастер.
Сначала руководителю полезно пройти общий входной вопросник: «С чего начать проект 1С:ERP: входной вопросник ERP-Мастер для руководителя». На этом входе выясняется, какие системы уже есть на предприятии, где ведётся инженерная подготовка, где сейчас ручной перенос данных и какие области должны попасть в первую очередь работ.
Затем важна статья «Как ERP-Мастер строит справочную структуру предприятия в 1С:ERP». Интеграция инженерных систем почти всегда упирается в справочную структуру: номенклатуру, виды номенклатуры, единицы измерения, склады, подразделения, рабочие центры, ресурсные спецификации, операции, виды работ, статьи калькуляции и дополнительные реквизиты.
Ещё один связанный материал — «Бизнес-процессы в 1С:ERP: от вопросника и интервью до автоматизированных инструкций». Обмен инженерных данных нельзя проектировать отдельно от процессов: производство, закупки, склад, кооперация, качество, выпуск, себестоимость и закрытие периода должны понимать, какие данные они получают и как их используют.
И наконец, статья «Vanessa Automation и автоматизированные инструкции» показывает, как такие сценарии потом проверять на тестовой базе: загрузка ресурсной спецификации, проверка номенклатуры, этапов, операций, рабочих центров, норм времени, кооперации и результата в 1С:ERP.
Навигация для читателя
Если вы только начали обсуждать ERP-проект — начните с входного вопросника.Если у вас уже есть проблема с номенклатурой и справочниками — прочитайте статью о справочной структуре.Если у вас есть внешняя инженерная система и ручной перенос в ERP — эта статья как раз про границу между инженерным языком и производственно-учётным языком 1С:ERP.
Почему инженерная система и ERP говорят на разных языках
Инженерная система отвечает на один класс вопросов. Как устроено изделие? Какие у него детали и сборочные единицы? Какие версии действуют? Какие чертежи актуальны? Какие атрибуты заполнены? Какие техпроцессы и маршруты описаны? Что разрешено к применению? Какие изменения внесены в конструкцию или технологию?
1С:ERP отвечает на другой класс вопросов. Что нужно произвести? Какие материалы закупить? Какие полуфабрикаты выпустить? Где хранить? Что списать? Какой этап производства создать? В каком подразделении выполняется операция? Какой рабочий центр использовать? Как рассчитать себестоимость? Как отразить кооперацию? Какие нормы времени и материалов применить? Что можно менять в запущенном производстве, а что уже относится к фактическому учёту?
Проблема возникает на границе этих двух языков. Инженерная система может быть корректной для конструктора и технолога, но недостаточной для ERP. В ней может быть объект, обозначение, маршрут, атрибут, состояние, ссылка на техпроцесс, но в ERP при этом не определены вид номенклатуры, единица хранения, статья калькуляции, производственное подразделение, рабочий центр, этап производства или правило кооперации.
Если просто «перегрузить» данные, можно получить ресурсную спецификацию, которая внешне похожа на заполненную, но не работает как управленческий объект ERP. Она не даёт правильного планирования, не формирует корректную потребность, не поддерживает себестоимость и не помогает производству.
Реплика ERP-Мастер
Ошибка многих интеграций в том, что они начинаются с вопроса: «Как выгрузить данные из инженерной системы?» Правильный вопрос другой: «Какая производственная и учётная структура нужна 1С:ERP, и какие инженерные данные нужны, чтобы эту структуру заполнить?»
Почему «кнопочный обмен» обычно не спасает
Идея «сделайте кнопку, чтобы всё грузилось само» звучит естественно. Руководитель видит: в инженерной системе уже есть изделие, состав, детали, маршруты, материалы. В ERP тоже есть справочники и ресурсные спецификации. Кажется, осталось только настроить обмен.
На практике обмен быстро упирается в вопросы, которые нельзя решить одной кнопкой. Какой вид номенклатуры назначить детали? Это материал, полуфабрикат, готовая продукция, стандартное изделие, метиз, заготовка или покупная деталь? В каких единицах хранить и списывать? Откуда взять массу? Как назначить статью калькуляции? Как понять, что является материалом, а что производимым полуфабрикатом? Как отразить побочный выход? Как сформировать этапы производства? Как сопоставить код участка из инженерной системы с подразделением ERP? Как определить рабочий центр? Как обработать маршрут с кооперацией? Что делать, если данные в инженерной системе отсутствуют?
Часть этих данных действительно должна приходить из инженерной системы. Но часть должна задаваться на стороне ERP через справочники, константы, правила мэппинга, дополнительные реквизиты и настройки загрузки. А часть данных у конструкторов и технологов вообще не обязана быть. Например, статья калькуляции, управленческая аналитика, отдельные правила финансового учёта или распределения затрат могут быть не инженерными, а ERP-данными.
Поэтому ERP-Мастер рассматривает интеграцию не как технический обмен, а как проектирование границы между двумя системами.
Что должно попасть в 1С:ERP
Внешняя инженерная система может хранить богатую техническую структуру изделия, но 1С:ERP должна получить управляемую производственную структуру.
В первую очередь это номенклатура. Для ERP недостаточно наименования и обозначения. Нужны виды номенклатуры, единицы хранения, единицы измерения, характеристики, серии или партии, масса, признаки закупки или изготовления, финансовые группы, дополнительные реквизиты, ответственные, правила заполнения и контроля.
Затем ресурсная спецификация. Она становится центральным узлом обмена: выпускаемая продукция, полуфабрикаты, материалы и работы, побочный выход, нормы расхода, источник поступления, признак обособленности, статьи калькуляции, состояние спецификации, статус применения и связь с изделием.
Дальше производственный процесс. Техпроцесс из инженерной системы должен превратиться в этапы производства ERP: с порядком выполнения, наименованием этапа, операциями, длительностью, подразделением, рабочими центрами и настройками производства. Если этапы формируются без подразделений, рабочих центров или наименований, производственная структура будет неполной.
Отдельный слой — рабочие центры и оборудование. Для ERP важно не только знать, что в инженерной системе есть операция, но и понимать, где она выполняется, каким видом рабочего центра, в каком подразделении, с какой доступностью и какими ограничениями.
И ещё один слой — нормы. ERP должна получить нормы материалов, нормы времени, подготовительно-заключительное время, трудозатраты, правила пересчёта и обновления. При этом важно не разрушить фактический учёт: если производство уже завершено, нормативы нельзя просто переписать задним числом.
Ресурсная спецификация как центральный узел обмена
В 1С:ERP ресурсная спецификация связывает инженерную структуру изделия с производством и учётом. Именно через неё предприятие начинает отвечать на практические вопросы: что выпускаем, из чего выпускаем, какие полуфабрикаты нужны, какие материалы списываются, какие операции выполняются, какие этапы формируются, где возникает побочный выход, как считается себестоимость.
Поэтому интеграция инженерной системы с ERP почти всегда проходит через ресурсную спецификацию. Но ресурсная спецификация — не копия инженерного дерева. Это ERP-объект, который должен быть пригоден для планирования, обеспечения, выпуска и учёта.
Например, полуфабрикат в инженерной системе может быть частью дерева изделия. В ERP нужно понять, создаём ли для него номенклатуру, какой вид номенклатуры назначаем, является ли он производимым, как он попадает в материалы и работы, нужен ли побочный выход, как отражается промежуточный выпуск между этапами и как он влияет на себестоимость.
Материал тоже не является просто строкой из спецификации. ERP должна понимать норму расхода, единицу хранения, статью калькуляции, источник поступления, складскую аналитику, замены, аналоги, закупку, списание и связь с выпуском.
Реплика ERP-Мастер
Ресурсная спецификация — это не место, куда «свалили дерево изделия». Это узел, где инженерная структура превращается в производственную и учётную логику ERP.
Номенклатура: почему вид, единица хранения и статья калькуляции не мелочи
Когда интеграция обсуждается на уровне «передать состав изделия», кажется, что номенклатура — это техническая подробность. На самом деле именно здесь часто ломается весь обмен.
Если номенклатура создаётся без вида, ERP не понимает, как применять настройки. Если не заполнена единица хранения, начинаются ошибки склада и списания. Если масса или вес не передаются, страдают расчёты, логистика и производственные параметры. Если статья калькуляции не назначена, дальше возникают проблемы с себестоимостью. Если не определён источник поступления, система не понимает, покупать позицию, производить её или получать через кооперацию.
Для металла, метизов, стандартных изделий, полуфабрикатов, готовой продукции, заготовок, покупных деталей и услуг переработки могут потребоваться разные правила. Иногда вид номенклатуры определяется по типу объекта. Иногда — по началу наименования. Иногда — по маршруту. Иногда — по атрибуту инженерной системы. Иногда — по дополнительной таблице соответствия на стороне ERP.
Поэтому в проекте интеграции обязательно проектируются правила номенклатуры: что приходит из инженерной системы, что дополняется ERP-правилами, что проверяется при загрузке и какие ошибки должны попадать в протокол.
Техпроцесс, этапы, операции, подразделения и рабочие центры
В инженерной системе маршрут или техпроцесс может быть понятен технологу. Но ERP должна превратить его в управляемый производственный процесс.
Например, маршрут может содержать последовательность операций или кодов участков. Для ERP нужно определить этапы производства, порядок выполнения, наименование этапа, подразделение, операцию, рабочий центр или вид рабочего центра, длительность, параметры собственного производства или внешней кооперации.
Если в инженерной системе есть код участка, его нужно сопоставить с производственным подразделением ERP. Если есть оборудование, его нужно сопоставить с рабочим центром или видом рабочего центра. Если в техпроцессе отсутствует операция, ERP должна понимать, можно ли создать операцию по умолчанию или это ошибка исходных данных, которую нужно вернуть заказчику.
Без такого мэппинга ERP будет получать формальные этапы, которые нельзя использовать для планирования, загрузки, контроля и себестоимости.
Связанный материал
Здесь напрямую проявляется тема справочной структуры предприятия: подразделения, рабочие центры, виды рабочих центров, операции и виды работ должны быть спроектированы не сами по себе, а из производственного процесса и правил учёта.
Кооперация, переработка и заготовки: почему один маршрут может означать разные сценарии
Отдельная сложность — кооперация, услуги переработки и заготовки. Один и тот же маршрут в инженерной системе может означать разные управленческие сценарии в ERP.
Позиция может быть покупной деталью. Может быть материалом для дальнейшей обработки. Может быть заготовкой. Может передаваться внешнему переработчику. Может возвращаться как полуфабрикат. Может проходить термообработку, гальванику, покраску или другую услугу переработки внутри общего маршрута. Для инженера это может быть один маршрут. Для ERP это разные процессы: закупка, передача в переработку, собственное производство, внешний этап, возврат, списание, выпуск, себестоимость.
Именно поэтому интеграция не может ограничиться полем «маршрут». Нужны правила интерпретации маршрутов и условий: когда создаётся этап собственного производства, когда внешний переработчик, когда услуга переработки, когда позиция должна идти в закупку как готовая деталь, когда нужно формировать заготовительный этап.
Отдельная будущая тема — заготовки для деталей. Раскрой или кадрирование заготовок, учёт заготовок, планирование потребности, нормирование заготовок и связь заготовки с деталью — это отдельная серьёзная область. В зависимости от производства эта задача может решаться на стороне инженерной системы, на стороне 1С:ERP или в комбинированном варианте. Универсального ответа здесь нет. Место решения определяется тем, как предприятие проектирует изделие, нормирует материалы, планирует производство и учитывает движение заготовок.
Реплика ERP-Мастер
Вопрос заготовок нельзя замести под ковёр. Если предприятие работает с деталями, раскроем, механообработкой или сложными маршрутами, тема заготовок становится отдельной задачей интеграции инженерной системы и ERP.
Средства технологического оснащения: почему учёт инструмента без инженерной системы неполон
Ещё одна область, которую нельзя терять, — средства технологического оснащения. Часто их пытаются рассматривать только как складской учёт инструмента или оснастки: есть инструмент, он хранится, выдаётся, возвращается, ремонтируется, списывается. Это важно, но недостаточно.
Для производства принципиально важно другое: где и зачем это средство технологического оснащения нужно. Для какой операции? Для какого изделия? Для какого рабочего центра? На какой ресурс? С каким сроком службы? С каким ремонтом? С какой потребностью? С какой заменой? С каким ограничением?
Проектирование и нормирование средств технологического оснащения — инженерная задача. Если система учёта инструмента в ERP не связана с инженерной системой, она может показать наличие или отсутствие оснастки на складе, но не всегда сможет правильно спланировать потребность и применение. В результате производство видит инструмент уже как проблему, а не как часть заранее рассчитанной ресурсной спецификации.
Поэтому системы учёта инструмента, оснастки и средств технологического оснащения должны быть сопряжены с инженерными системами. Тогда ERP может не просто учитывать факт выдачи, а связывать средство технологического оснащения с ресурсной спецификацией, операцией, рабочим центром, графиком производства, ресурсом, ремонтом и себестоимостью.
Нормы времени и изменение уже запущенного производства
Интеграция инженерной системы и ERP становится особенно тонкой, когда меняются нормы времени или подготовительно-заключительное время. В инженерной системе технолог может обновить норматив. ERP должна получить это изменение и обновить ресурсную спецификацию. Но дальше возникает вопрос: что делать с производственными документами, которые уже созданы?
Если этап производства ещё не начат или находится в состоянии подготовки, обновление может быть допустимо. Если этап уже запущен, нужно понимать, можно ли обновлять плановые показатели. Если этап завершён, менять документы нельзя: это исказит фактический учёт трудозатрат и результаты производства.
Значит, интеграция должна учитывать статусы этапов, правила отбора документов, логирование изменений, ошибки блокировки, повторные попытки, ручные корректировки и разграничение плановых и фактических данных.
Это хороший пример того, почему интеграция инженерной системы и ERP — не просто загрузка данных. Она затрагивает живое производство. Любое изменение может повлиять на смены, мастеров, нормочасы, себестоимость и закрытие периода.
Почему интеграцию нужно тестировать на реальных изделиях
Интеграцию нельзя проверять только на учебной спецификации из трёх строк. Нужно брать реальные изделия, реальные сборочные единицы, реальные материалы, реальные полуфабрикаты, реальные маршруты и спорные случаи.
Только на реальных примерах видно, где не заполнен вид номенклатуры, где отсутствует единица хранения, где не назначена статья калькуляции, где не сформировался межоперационный полуфабрикат, где не подгрузился производственный процесс, где отсутствует код участка, где не сопоставился рабочий центр, где маршрут означает кооперацию, а где собственную обработку.
Тестирование должно фиксироваться протоколом. Ошибка может быть на стороне ERP-правила, на стороне обмена, на стороне исходных инженерных данных или на стороне методики предприятия. Это важно различать. Если в инженерной системе нет маршрута, ERP не должна «угадать» его молча. Если в ERP нет сопоставления подразделения, это отдельная задача мэппинга. Если данные загружаются дважды, это ошибка правил идентификации. Если при повторной загрузке возникает конфликт уникальности, это нужно фиксировать и исправлять.
Реплика ERP-Мастер
Хорошая интеграция отличается от плохой не тем, что «не бывает ошибок». Ошибки будут. Хорошая интеграция умеет показать, где именно ошибка: в исходных инженерных данных, в мэппинге, в ERP-структуре, в коде обмена или в правилах повторной загрузки.
Что получает заказчик
Заказчик получает не просто технический обмен. Он получает проектную карту границы между инженерной системой и 1С:ERP.
В эту карту входят целевая структура ERP, список инженерных источников, мэппинг объектов, правила преобразования, правила дополнения данных на стороне ERP, требования к номенклатуре, ресурсным спецификациям, этапам, операциям, рабочим центрам, подразделениям, кооперации, заготовкам, средствам технологического оснащения, нормам времени и материалам.
Кроме того, заказчик получает техническое задание на доработку или настройку обмена, тестовые сценарии, протоколы загрузки, список ошибок исходных данных, список решений по спорным случаям и правила сопровождения изменений.
Для руководителя это означает, что обмен перестаёт быть «чёрным ящиком». Становится понятно, какие данные приходят из инженерной системы, какие дополняются на стороне ERP, какие ошибки блокируют производство, а какие требуют методического решения.
Для главного инженера это означает, что инженерная система не теряет своё назначение и не превращается в придаток ERP. Для директора по производству — что ERP получает данные, пригодные для планирования. Для финансового директора — что ресурсная спецификация начинает поддерживать себестоимость. Для ИТ — что обмен можно сопровождать, тестировать и развивать.
Где граница ответственности ERP-Мастер
ERP-Мастер не заменяет подрядчика по PDM/PLM/CAD и не внедряет инженерную систему вместо профильных специалистов. Мы не утверждаем, что один инженерный продукт лучше другого. В разных производствах могут быть разные решения: для механообработки одни, для электротехники другие, для конструкторской документации третьи, для технологической подготовки четвёртые.
Наша зона — связка с 1С:ERP. Мы помогаем ответить на вопросы: какая ERP-структура нужна предприятию, какие инженерные данные нужны для её заполнения, как их преобразовать, что дополнить на стороне ERP, где нужны константы и правила, какие ошибки проверять, как тестировать обмен и как сопровождать изменения.
Позиция ERP-Мастер
Мы не выбираем за предприятие инженерную систему. Мы помогаем сделать так, чтобы данные из этой инженерной системы стали рабочими данными для 1С:ERP.
С чего начать
Начинать нужно не с вопроса «какую кнопку обмена нажать», а с вопроса: какая производственная и учётная структура нужна ERP?
Сначала нужно понять номенклатурные группы, ресурсные спецификации, этапы, операции, рабочие центры, подразделения, статьи калькуляции, правила кооперации, заготовки, средства технологического оснащения, нормы и требования к себестоимости. Затем — определить, какие данные для этой структуры уже есть во внешней инженерной системе, какие нужно мэппить, какие нужно дополнить на стороне ERP, а какие являются проблемой исходных инженерных данных.
Практический первый шаг — пройти входной вопросник ERP-Мастер. После него можно подготовить отдельный адаптированный вопросник по инженерным системам: какая система используется, какие данные в ней ведутся, какие изделия выбрать для тестовой загрузки, где сейчас ручной перенос, какие ошибки уже известны, какие ресурсные спецификации считаются проблемными и что должно войти в первую очередь работ.
Финальная реплика ERP-Мастер
Если внешняя инженерная система знает, как изделие устроено, а 1С:ERP должна знать, как его произвести, закупить, списать и посчитать, между ними нужен не файл, а правила перевода. Причём сначала нужно понять, какая производственная и учётная структура нужна ERP, и только потом определять, какие данные приходят из PDM/PLM/CAD, а какие должны быть дополнены на стороне ERP. Эти правила и проектирует ERP-Мастер.