Поделиться
Интеграция САПР и ERP: ищем подводные камни
В вопросе интеграции САПР и ERP систем существует множество неочевидных на первый взгляд моментов, зачастую замалчиваемых представителями фирм, предлагающих построение интегрированных решений. На практике "тотальная" интеграция практически невозможна. Хотя эксперты, опрошенные CNews, не совсем согласны с этой точкой зрения.К сожалению, на российских предприятиях до сих пор подразделения нацелены не на достижение общих целей, а на выполнение своих узких задач, которые могут вести совершенно в другую сторону. Например, зачастую технические службы существуют на предприятии исключительно ради создания "бумаги". Потому как трудно по-другому охарактеризовать ситуацию, когда на предприятии в производстве никто и никогда не видел документации из технических служб – в основном изделия изготавливаются на основе "самописных" аналогов спецификации и нарисованных в цеху эскизов. В то же время, десятки конструкторов и технологов не поднимая головы корпеют над своими трудами, их руководство ходатайствует об увеличении штатов по причине чрезмерной загрузки сотрудников. И попробуйте спросить руководство технических служб предприятий о целях и задачах их подразделений – вы непременно услышите ответ: "выпустить техническую документацию и сдать ее в архив". Или же производство штампует сотни и тысячи деталей только из резона 100% загрузки оборудования для повышения эффективности и занятости рабочих, получающих сдельную заработную плату, нисколько не задумываясь о реальной потребности предприятия в таких деталях. Авось когда-нибудь пригодятся. А тем времени на складах в виде таких деталей оказываются замороженными значительные финансовые ресурсы.
С другой стороны, представители фирмы, внедряющей САПР на предприятии хорошо представляют специфику работы своей системы и технических служб, но, зачастую, довольно слабо знакомы с особенностями и принципами ERP-систем. И наоборот – можно сделать такие же выводы о познаниях в области технической подготовки производства и САПР у представителей фирм, внедряющих на предприятиях ERP системы. Когда начинается процесс обсуждения проблем интеграции, за стол переговоров садятся люди, говорящие "на разных языках". И тут начинается самое интересное.
Что делать и с какой целью?
Обычно целью ставится так называемая "тотальная" интеграция, когда в САПР полностью ведется вся подготовка производства. Полный объем информации автоматически транслируется в ERP систему. Идея, конечно же, очень красива, но в реальности она оказывается не менее утопичной.
Системы САПР, цель которых - автоматизация труда конструкторов и технологов, имеют структуру, ориентированную на создание и хранение подробнейших данных, необходимых для производства изделия. ERP-системы, ориентированные на поддержку принятия управленческих решений, вовсе не нуждаются в такой глубокой детализации технических данных. Более того, такая детализация может быть даже пагубна для них. Нагляднее всего это видно на маршрутах. Маршрут – понятие из ERP-систем. Для таких систем маршрут – это последовательность операций, необходимых для превращения компонент в изделие. Причем это должен быть сквозной маршрут – от получения компонентов со склада или из цеховой кладовой, до сдачи детали, сборочной единицы или готового изделия на склад. Детализация операций должна быть такой, чтобы позволить пронормировать эти операции – ведь именно ради этого в основном и присутствует понятие маршрута в ERP системах.
В САПР же понятие маршрута вообще не существует. Зато существует привычное технологам понятие технологического процесса (ТП). Причем это могут быть как индивидуальные ТП, так и типовые и групповые (идентичные по технологическому признаку для разных групп деталей). Например, процесс производства одной детали может описываться ТП механической обработки и типовыми ТП гальванической обработки и окраски (сначала заготовка обрабатывается на токарном станке (ТП механической обработки), затем идет гальваническая обработка (типовой ТП), потом шлифуется (снова ТП механической обработки) и затем красится (типовой ТП)). Встает разумный вопрос – как из этого набора ТП автоматически сформировать маршрут, необходимый для ERP? Можно конечно просто включить все подряд операции из ТП и таким образом получить желанный маршрут, но тогда объявит бойкот производство, когда в цеха спустятся маршрутные карты, каждая длиной в сотню метров, и необходимо будет производить регистрацию выполнения каждой из сотен таких операций в ERP-системе.
Да и такая детализация просто вредна при анализе данных, ведь для принятия управленческого решения вполне достаточно знать местоположение партии деталей с точностью до цеха или до тех или иных проблемных мест в цехах. А если нельзя попросту включать все операции подряд в маршрут, то значит надо их укрупнять по каким-то принципам, что предоставляется малореальным в полностью автоматическом режиме.
Кроме различия в степени детализации данных, два типа систем отличаются структурой этих данных, что является даже более существенной проблемой. Вот некоторые примеры.
В САПР, в соответствии с ЕСКД, состав сборочных единиц описывается документом "Конструкторская спецификация". На каждую сборочную единицу формируется такой документ, и он содержит перечень всех подсборок и деталей с требуемым количеством, необходимых для того, чтобы изготовить данную сборочную единицу. Также в спецификацию вносится тип материалов и их количество, которые необходимы для сборки. В ERP же спецификация имеет другой смысл. В таких системах она формируется на любой изготавливаемый объект. То есть в ERP должны быть сформированы спецификации даже на детали, однако в САПР не существует спецификаций на детали. Выходит, что материалы для изготовления деталей необходимо брать из ТП.
Но тогда встает вопрос: какие вспомогательные материалы следует передавать в ERP? Передавать все нельзя по той простой причине, что в ERP материалы в спецификацию включаются по признаку отнесения их к прямым затратам. Технолог же нормирует вспомогательные материалы, отталкиваясь совсем от других критериев. Также нельзя автоматически брать для спецификации ERP материалы для сборочных единиц из конструкторских спецификаций. Ведь если в конструкторскую спецификацию заносится количество материала непосредственно необходимого для сборки, то в ERP нужно занести количество с учетом технологических и статистических потерь данного материала при сборке, чтобы гарантированно обеспечить возможность сборки. А эту информацию не всегда можно получить даже из ТП. Таким образом, передавать состав из САПР в ERP представляется крайне затруднительным, а, скорее всего и невозможным в полностью автоматическом режиме.
Другая проблема, касающаяся состава – это наличие так называемых "фантомных" изделий. Особенность работы конструктора в том, что он проектирует изделие, не привязываясь к технологии его изготовления, что вполне понятно. Это, однако, приводит к тому, что в конструкторских спецификациях присутствуют сборочные единицы, которые сами по себе в производстве и на складах не существуют – для производства они как фантомы. Особенно это характерно для конвейерных и поточных производств, когда подсборка, имеющая свой чертеж и обозначение и внесенная в спецификацию изделия, не подается на сборку изделия в качестве компонента, а подсобирается непосредственно при сборке самого изделия. Если такие "фантомы" просто перегружать из конструкторских спецификаций в ERP, то производство начнет получать указания из системы на получение со складов материалов и деталей для таких подсборок, изготовление этих подсборок и сдачу их на склад. Привыкшее к тому, что эти материалы и детали надо получать как комплектацию самого изделия, а не подсборок, не представляющее о какой вообще подсборке идет речь, производство просто "встанет на уши". То есть все склоняется опять к тому, что без "ручной" работы с данными в ERP не обойтись.
Вопрос с технологическими деталями также не прост при решении вопросов интеграции. Ведь технологические детали вполне объяснимо отсутствуют в конструкторской спецификации, однако должны присутствовать в спецификации ERP. И тут вопрос в том, по каким принципам отбирать их из ТП и опять же, как потом передавать изменения спецификаций и маршрутов из САПР и отражать их в ERP?
Последний из камней преткновения в структурах данных САПР и ERP, которые будут затронуты в этой статье – это перегрузка производственных ресурсов. В ERP под этим понятием подразумеваются не расходуемые ресурсы, которые необходимы для обеспечения выполнения операций (например, оборудование, персонал, некоторые виды оснастки, некоторые виды технологических деталей). В ERP эти данные используются для расчета загрузки мощностей или для планирования с учетом загрузки. Однако, очевидно, что планировать загрузку необходимо не поголовно по всему оборудованию, и уж тем более не по всем видам оснастки и технологических деталей. И опять возникают неразрешимые трудности с определением критериев выбора ресурсов из ТП и перегрузки в ERP, снова возникает мысль о необходимости корректировки данных в ERP после перегрузки, и вновь упираемся в тупик при перегрузке изменений маршрутов, вследствие выпуска в САПР извещений об изменении ТП.
Что в сухом остатке?
Автор статьи вовсе не является противником интеграции, как могло показаться, исходя из написанного выше. При наличии на предприятии одной из систем и внедрении другой необходимо продумывать варианты интеграции двух типов систем. Но при этом не стоит гнаться за "тотальной" интеграцией. Оптимальным, на с точки зрения автора, является вариант, когда интеграция строится лишь на перегрузке спецификаций и маршрутов вновь разработанных изделий, а дальше вступает в дело специально организованная на предприятии группа, которая является буфером между системами. Работники этой группы формируют в ERP спецификации и маршруты в окончательном виде и отображают в них изменения при поступлении от технических служб соответствующих извещений. Сотрудники группы должны быть одновременно специалистами по технической подготовке производства и прекрасно представлять идеологию ERP, организацию производственных процессов на предприятии. Подготовить такую группу из своих сотрудников вполне может себе позволить любое предприятие. Тем самым параллельно разрешится вечный конфликт между подразделениями, работающими на локальные цели, и усилия технических служб будут направлены туда, куда они и должны быть направлены – в производство.
В статье автор умышленно абстрагировался от программных методов реализации интеграции, так как вне зависимости от того, будь это пакетная перегрузка данных или онлайн интерфейс с использованием API функций, главными проблемами остаются проблемы идеологической разности систем, и от методов перегрузки они практически не зависят.
Михаил Казанский / CNews
Короткая ссылка
