Подготовка нормативной информации для ERP

Иван Берендеев
Директор по перспективным разработкам компании «АППИУС»

В этой статье мы постараемся систематизировать аспекты подготовки нормативной информации для систем производственного планирования и учета. Как известно, взаимодействие любых программных систем состоит из двух частей: взаимодействие данных и взаимодействие процессов. Здесь мы рассмотрим только первую часть, то есть подготовку и управление данными. В качестве используемых информационных систем выберем программные решения на платформе «1С:Предприятие 8». Сначала рассмотрим, какие именно данные имеются в нашем распоряжении, определим их источники, затем проанализируем процессы управления ими в рамках существующих на предприятии схем работы и, наконец, поговорим об особенностях преобразования информации при взаимодействии с системой ERP. В качестве ERP-системы выберем систему «1С:Управление производственным предприятием» (далее 1С:УПП), не забывая о том, что в целом наш разговор применим для любой другой системы такого же класса.

Итак, основные источники первичной информации — это документы ЕСКД (электронные модели, чертежи, спецификации), нормативно­справочные системы и классификаторы (в электронном виде), документы ЕСТД (технологические процессы, ведомости). К технологической же подготовке будем относить информацию из отдела труда и заработной платы (ОТиЗ), а именно: тарифные сетки, профессии, разряды работ и условия труда. Кроме того, для организации детального посменного планирования с выбором наименее загруженного оборудования системе ERP требуется информация по группам заменимости оборудования, то есть совокупностям взаимозаменяемого оборудования. Мы сознательно не будем затрагивать в этой статье тонкости работы системы планирования, связанные с объединением оборудования в рабочие центры, подчинение рабочих центров друг другу, параллельность операций технологического процесса и некоторые другие вещи. Рассмотрим лишь общие примеры, характерные для большинства предприятий.

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

Информация из документов ЕСКД

Оговоримся сразу, что имеется несколько уровней детализации взаимодействия с системой ERP. При отсутствии технологии вы вполне можете ограничиться передачей в ERP информации только о структуре изделия, и для этого вам будет достаточно информации из конструкторской спецификации. Однако сами по себе спецификации, как единичная, так и групповая, оформляются таким образом, что напрямую их передавать в ERP­систему не совсем правильно, если не сказать больше. В спецификации хранится информация со сборочного чертежа с позициями комплектующих, вариантов замены, материалов и покупных изделий (прочих и стандартных). Как конструкторский документ она организована таким образом, чтобы соответствовать сборочному чертежу в фактическом его исполнении. Например, каждая комплектующая указывается с определенной позицией чертежа, материалы (особенно в изделиях из свариваемого проката) часто указываются в штуках определенных единиц длины (Труба… 2 шт. L=400), допустимые замены должны быть реализованы текстовыми примечаниями: только в текстовом виде можно указывать безусловные аналоги (замена которых возможна в любом случае). Наличие специфических разделов о дорабатываемых изделиях, диапазонное указание количества, имеющиеся заготовки — всё это не дает возможности работать с этим документом, как говорится, «в лоб». Это не значит, что спецификация не решает возложенных на нее задач, ведь для того, чтобы в полном объеме обработать эту информацию, нам нужна несколько более общая структурная единица информации, учитывающая описанные выше аспекты. При этом желательно иметь возможность из этой обобщенной структуры получать саму спецификацию и другие документы, например ведомость покупных. В том или ином виде такая структура существует в большинстве современных систем управления данными. Мы рассматриваем системы на платформе «1С:Предприятие», и здесь такая структура называется «электронная структура изделия», а создается она в конфигурации «1C:PDM Управление инженерными данными». Электронная структура изделия представляет собой совокупность компонентов изделия, организованных в виде дерева, где каждая отдельная подсборка имеет собственный состав, и так далее вниз до детали и основного материала. Естественно, каждый элемент такой структуры в соответствии со спецификацией может быть деталью или сборкой, материалом, стандартным или прочим изделием, комплектом, заменой и т.д.

Редактор ЭСИ 1С:PDM

Редактор исполнений

Редактор ЭСИ 1С:PDM

Получение электронной структуры изделия

Как можно получить электронную структуру изделия (далее ЭСИ)? Есть два пути: получать ее из системы проектирования CAD либо задать вручную при помощи редактора структуры изделия. При этом следует учитывать и тот факт, что информацию с бумажных спецификаций прошлых лет, даже если они оцифрованы в файл, весьма вероятно, придется вводить операторским вводом. Конструкторский отдел на предприятии работает в CAD­системе с геометрическими моделями и чертежами либо только с чертежами (двумерное проектирование). Что касается трехмерного проектирования, следует иметь в виду, что сама модель может проектироваться различно. Нередко таким образом, что трехмерная модель не отражает фактическую модель изделия, а, например, используется исключительно для облегчения построения чертежа с нее, что в принципе допустимо. Но в этом случае некоторые характеристики такой модели в процессе ее обработки при создании ЭСИ могут восприниматься как некорректные. Например, некоторые сборки могут быть реализованы деталями, массово­габаритные характеристики, наименования и обозначения изделий могут быть неверными или не заданы вовсе.

В том случае, если трехмерная модель, создаваемая конструктором, является верной с точки зрения фактического отражения геометрии изделия, либо у сотрудников имеется готовность к постобработке в редакторе структуры изделия, то можно воспользоваться средствами автоматизированного построения структуры изделия. В 1C:PDM такими средствами являются PLM­компоненты, реализованные ко всем распространенным CAD­системам. При помощи этих компонентов работы по созданию и управлению структурой изделия из CAD­системы существенно облегчаются. За счет возможности последующей обработки структуры изделия в редакторе структуры изделия привычная схема трехмерного проектирования не изменяется. Не указанные обозначения или наименования можно задать в редакторе структуры изделия и синхронизировать их затем с моделью или чертежом. Дополнительные сборочные материалы, не используемые в трехмерном проектировании (прокладки, смазки, жидкие материалы и т.д.), также задаются позже как элементы структуры изделия, а параметры длины, ширины — как свойства соответствующих элементов с последующей возможностью пересчета.

Большим плюсом организации электронной структуры изделия как отдельной от конструкторских документов информационной единицы является также и тот факт, что ее можно импортировать или создать не только на основании данных проектирования, но и используя данные из баз АСУ предприятия.

Информация с чертежа

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

Инженерный справочник

Нормативно­справочная информация

Актуальность использования электронной нормативно­справочной информации при конструкторском проектировании и технологической подготовке очевидна. Использование справочных данных не только сокращает время, но и гарантирует отсутствие их дублирования при занесении в конструкторские и технологические документы. В чем же особенность ведения справочной информации, которая в дальнейшем будет использоваться в системе ERP?

Первое, на что нужно обратить внимание, — это то, что справочная информация может заноситься и со стороны ERP­системы. Оставив за рамками обсуждение правильности такого подхода, заметим, что при запуске любой ERP­системы в нее заносятся так называемые начальные остатки, то есть то количество материалов, комплектующих и готовых изделий, которые к моменту ее запуска находятся на складах. К этому времени информация об элементах (номенклатуре) начальных остатков должна быть уже занесена в систему ERP. Занесение даже идеально выверенных справочных данных службами конструкторско­технологической подготовки производства, — очень трудоемкий процесс, поскольку необходимо иметь в системе управления инженерными данными всю информацию о выпускаемых изделиях и технологии. Косвенно это должно свидетельствовать о том, что запуск системы ERP желательно производить после или во время внедрения системы PDM, — в этом случае информация о материалах и комплектующих попадет в систему ERP из PDM и не потребует последующей синхронизации. Однако чаще всего ситуация прямо противоположная. Пытаясь внедрить систему ERP и сталкиваясь с тем, что информация о комплектующих вводится в нее по мере поступления самих этих комплектующих, причем, как правило, они заносятся по первичным документам с названиями, не всегда соответствующими ЕСКД и ЕСТД, предприятие через какое­то время получает два больших набора данных (в том числе и справочных). Один набор находится в ERP­системе, другой — в системе PDM у инженерных служб. Чтобы избежать описанных проблем или хотя бы сократить их количество, желательно иметь общие перечни применяемости (ограничительные перечни) не только для служб КТПП1, но и для производства. Это значит, что любой экземпляр материала или метиза, примененный в электронной структуре изделия, должен в неизменном виде попасть в систему ERP как можно быстрее — в противном случае службы снабжения будут вынуждены создавать его самостоятельно, не имея точной информации о названии, виде воспроизводства и других параметрах, либо будет затягиваться сам процесс закупки.

Второй важнейшей проблемой может стать использование различных наименований комплектующих. Службы конструкторов и технологов, работая по ЕСКД и ЕСТД и соответствующим образом формируя электронную структуру изделия и ограничительные перечни, руководствуются правилами наименования, заложенными в государственных или отраслевых стандартах, в то время как фактически поставляемая комплектующая, пусть и имеющая идентичные характеристики, указывается поставщиком, естественно, с собственным наименованием. Нередко бывают случаи, когда проще и быстрее купить, например, метизы по европейскому стандарту, аналогичные по характеристикам, заложенным в ЕСКД. При этом номенклатура поставщика меняется гораздо чаще, чем сама документация на выпускаемое изделие. Особенно это касается зарубежных поставщиков, так как срок выпуска комплектующих длится всего два­три года (электронные компоненты, например). И в этом случае наименование пришедших от поставщика изделий согласно ЕСКД вовсе не имеет смысла — концов потом не найдешь, и это особенно актуально для изделий с возможным возвратом на гарантийный или постгарантийный ремонт. Выход следующий: иметь в структуре изделия наименование согласно ЕСКД, а в ERP­системе — номенклатуру с собственным названием и осуществлять прямую связь между первым и вторым.

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

Возвращаясь к использованию принятых в начале статьи программных решений, отметим, что для организации единого с ERP справочника материалов и комплектующих вы можете воспользоваться конфигурацией «Инженерный справочник». Подробнее с ней вы можете познакомиться, обратившись к журналу «САПР и графика» № 9’2012.

Резюмируя рассказ о взаимодействии справочной системы и системы ERP, необходимо сказать следующее:

• наличия одного единого источника информации и для КТПП, и для ERP не всегда достаточно. Необходимо, чтобы система управления данными об изделии элементу справочника КТПП в структуре изделия могла найти аналог в системе ERP;
• в случае же принятия PDM­системы как единственного источника информации справочные данные необходимо передавать в ERP как можно быстрее, сразу после их попадания в электронный ограничительный перечень.

Технологическая подготовка производства

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

Начнем рассмотрение с понятия «технологический маршрут». Отметим сразу, что под ним подразумевается расцеховочный маршрут, то есть последовательность производственных подразделений, которую проходит изделие в процессе своего изготовления. Внутрицеховой маршрут изделия описывается маршрутной картой. Так ли необходим ERP­системе маршрут изготовления? Всё, естественно, зависит от сложности производства. Чаще всего ответ положительный: да, необходим. Опираясь на данные технологического маршрута,
ERP­система формирует производственные планы по цехам, заказы на производства, задания и т.п. Цех, как правило, также является единицей учета, то есть регистрируются входящие в цех материалы и полуфабрикаты, фиксируется выпуск. Технологический маршрут неразрывно связан с системой полуфабрикатного учета. При ведении сквозных технологических процессов, то есть включающих операции всех методов обработки, технологический маршрут не составляется отдельно, а формируется автоматически (в системе 1С:PDM) на основе маршрутной карты.

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

Следующим элементом для рассмотрения является технологический процесс. Здесь мы будем следить только за его маршрутным описанием, не затрагивая операционное, работу с эскизами, программы ЧПУ и т.д., ведь в подавляющем большинстве случаев ERP­система не детализирует технологию до переходов. Итак, маршрутное описание технологического процесса содержит последовательность операций, в которых указывается: вид и наименование операции, оборудование, штучное и подготовительно­заключительное время, разряд работ, профессия, условия труда и еще ряд других параметров. Если технологический процесс единичный, то маршрутное описание содержит и информацию об основном материале.

Единичные технологические процессы по методам обработки

Единичные технологические процессы по методам обработки, подключенные затем к соответствующим пунктам маршрута, помимо описанных выше параметров включают информацию об основном материале и норме его расхода. Эта информация также необходима ERP­системе для того, чтобы правильно рассчитать потребность в материалах. В маршрутном описании технологического процесса ERP­системе также необходимо иметь информацию о расходе вспомогательного материала, например СОЖ, и используемом инструменте. Маршрутное описание техпроцесса предполагает наличие такой информации.

Как правило, системы ERP ориентированы на использование сквозных технологических процессов. Это значит, что из маршрута и подключенных к его пунктам техпроцессов необходимо создать сквозное маршрутное описание (список операций) таким образом, чтобы оно точно соответствовало логике изготовления, заложенной технологом. Эта несложная операция выполняется программой в автоматическом режиме.

Типовой ТП с вариантами комплектования по исполнениям

Многозаходные технологические процессы и их передача в ERP

В предыдущем разделе мы увидели, что преобразование маршрута и техпроцессов в сквозное маршрутное описание можно сделать в автоматическом режиме, однако дело осложняется наличием так называемых многозаходных технологий. Во время механической обработки детали может потребоваться, например, отжиг в термическом цехе, остывание и продолжение механической обработки согласно этому же техпроцессу. В таком случае технолог в маршрутном описании в разрыве операций механической обработки пишет фразу, подобную следующей: «Выполнить отжиг по техпроцессу АБВГ.0001….», и продолжает запись операций, предполагая, что деталь уже получена из термического цеха. Маршрут в этом случае будет содержать примерно следующее (01 — механический цех, а 05 — термический) 01­05­01, то есть второй заход в механический цех. С точки зрения технолога и здравого смысла все правильно. Но если такую технологию попытаться передать в ERP описанным выше способом, полученное сквозное описание будет неверным, так как во втором заходе должны быть только операции, следующие после термической обработки изделия, а в первом заходе идущие до нее. Естественно, в разрыв операций должны быть вставлены операции термического техпроцесса. Есть несколько способов решения этой проблемы — от указания номера начальной операции до использования ссылок на операции в пунктах маршрута, как, например, реализовано в 1C:PDM.

Типовые и групповые технологические процессы

Передача в ERP­систему типовых и групповых технологических процессов часто осложняется их некорректным представлением в системах технологической подготовки производства. В тех системах, где общая часть технологического процесса оторвана от ведомости деталей, сделать это весьма затруднительно. Чем же осложняется процесс передачи типовых и групповых ТП в ERP­систему? Как известно из ЕСТД, постоянная (общая) часть типового технологического процесса общего вида выполняется на карте типового техпроцесса. Затем к ней оформляется ведомость деталей, в которой перечисляются изменения в операциях для конкретного изделия или группы изделий. Реализовывать в ERP­системе работу с типовыми технологическими процессами не имеет смысла, так как каждая деталь всё равно изготавливается по конкретизированной части типового техпроцесса. Вопрос только в том, как из типового техпроцесса с ведомостью деталей сделать набор единичных техпроцессов с определенными нормами и материалами? Осуществлять этот процесс вручную бессмысленно, поскольку его трудоемкость сведет на нет все преимущества типизации. Очевидно, он должен быть автоматизирован, то есть программа автоматически должна формировать на основе известного списка деталей из ЭСИ конкретизацию всех типовых техпроцессов, получая из них единичные. В 1C:PDM это делается специализированным механизмом конкретизации техпроцесса. Вкратце он сводится к следующему. Для имеющейся общей части технологического процесса технолог вносит изменения и сохраняет их для определенной детали из группы. Группа содержит все возможные детали, для которых может быть применен данный техпроцесс. Эти изменения сохраняются версиями всех объектов техпроцесса от операции до перехода, материала, нормы и т.д. Затем, при передаче изделия в ERP, состав этого изделия служит автоматической конкретизацией для типовых техпроцессов, то есть осуществляется выбор тех параметров ведомости деталей типового ТП, которые соответствуют обрабатываемому компоненту структуры изделия.

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

Структуры данных ERP. Обобщение

Сборочные технологические процессы

Одной из самых интересных задач является передача сборочных технологических процессов в ERP­систему. Описание технологического процесса сборки изделия (сварки и т.д.) характеризуется довольно объемным текстом, а также указанием позиций комплектующих для соединения. Причем в одном технологическом процессе могут быть использованы комплектующие из различных подсборок одного изделия, если это продиктовано особенностью изготовления. Кроме того, комплектовочные операции сборки предполагают непосредственную привязку состава сборочной единицы к операции (комплектовочная карта), причем количество комплектующих, исходя из особенностей регулировки, наладки, да и просто самого процесса сборки, может быть увеличено. Здесь следует отметить и такой знакомый многим термин, как «технологический состав», который как раз и предполагает построение новой структуры изделия с перегруппировкой комплектующих по процессам изготовления. Технологический состав может быть получен как для организации проектирования техпроцессов, так и во время их проектирования на основании процессов сборки. При управлении данными техпроцессов сборки необходимо помнить о важной их особенности — наличию фантомных сборочных единиц. Здесь слово «фантомный» используется в значении «исчезающий». Как правило, фантомами являются подсборки, появляющиеся в процессе изготовления более крупного узла и не подлежащие производственному планированию и учету в ERP ввиду отсутствия такой необходимости. Для ERP­системы каждая подсборка изделия может быть фантомом. Чем больше фантомных сборочных единиц, тем меньше единиц планирования и учета, однако сложнее проводить контроль выполнения производства и управление комплектацией. Работа с неподлежащими учету сборочными узлами регулируется ERP­системой, но в некоторых случаях развернуть фантомную сборку на составляющие компоненты может и система PDM при передаче данных в систему планирования, как это делает 1C:PDM.

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

Структуры данных ERP. Обобщение

Любая ERP­система в том или ином виде содержит исходную информацию по всем составляющим изделия, а также технологию в виде маршрутов и маршрутных описаний технологических процессов. Самое существенное отличие кроется в том, что привычное нам раздельное описание спецификаций, ведомостей, технологических процессов разного вида хранится в ней, как правило, в двух единых структурах: производственных спецификациях, описывающих количественную взаимосвязь исходных комплектующих, материалов, покупных изделий и деталей, и технологических маршрутов или маршрутных карт (названия, естественно, могут отличаться), которые сохраняют технологию на эти производственные спецификации. А значит, для ERP­системы даже деталь имеет спецификацию, компонентом которой будет один или несколько основных материалов с нормами расхода и вспомогательный материал, применяемый при ее изготовлении, возвратный отход (стружка) и т.д. Каждая исходная комплектующая будет иметь связь с определенной операцией сквозного маршрутного описания изготовления этой детали. В производственных спецификациях указывается и дополнительная информация, например статьи затрат, доли стоимости, побочные выходы при производстве.

Формирование таких спецификаций и маршрутов вручную — трудоемкая задача, а, учитывая объемы данных в единицу времени, зачастую и невыполнимая. Дело в том, что на каждое изменение в технологии или составе для измененного узла или детали необходимо формирование новой производственной спецификации (версии), так как по предыдущей уже выполняется производственный учет и зафиксированы факты выпуска, сформированы планы и осуществлены закупки. Для того чтобы информация в ERP­системе была корректной, необходимо учитывать множество факторов, начиная от логики работы самой такой системы и заканчивая пониманием всех источников первоначальных данных для ее работы.

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

1 Конструкторско­технологическая подготовка производства.

САПР и графика 5`2013