Введение и сопровождение корпоративной БД изделий

[MBugriy]

Хочется обсудить вопрос о том, кто и как внедряет EPLAN в качестве корпоративного САПРа предприятия. В первую очередь как организуется ведение и сопровождение корпоративной БД изделий?

[MBugriy]

По моему глубокому убеждению работу с EPLANом нужно вести непременно использую общую корпоративную БД по следующим причинам:
1) Корпоративная БД является инструментам для контроля движения материальных ценностей на предприятии и применимости их в проектах; Данная БД должна являться первоисточником для запуска информации об изделии в электронный документооборот предприятия (в системы PDM и ERP). Если данный уровень IT инфраструктуры отсутствует, это подготавливает правильную основу для его появления.
2) Коллективное редактирование БД позволяет суммировать (с целью совместного использования) усилия пользователей потраченные на систематизацию основных данных EPLAN. Ведение собственной БД каждым пользователем экономически не целесообразно.
3) Корпоративная БД позволяет использовать её в качестве ограничительного перечня предприятия.

[MBugriy]

Когда мне приходилось сопровождать внедрение EPLAN мной были написаны некие прообразы стандартов предприятия. Сейчас бы я многое по-другому написал, но мы внедряли 1.8.5 опыта было мало и спросить было некого. Многое из написанного в данных документах изначально мертворождённое и надуманное, но некоторые правила используются мной до сих пор.
Как показывает практика, нельзя отдавать создание корпоративной БД на самотёк иначе получается большая "помойка". Люди сидящие за соседними столами не могут договориться, что в какое поле БД, что заносить, а когда на заводе 70 лицензий и пользователи лично друг с другом не общаются... как быть?
Если не задать правила то неизбежно в БД будут появляться изделия "двойники", разделы типа "прочее", "другое", "разное" и найти что либо в такой базе будет невозможно. Надеятся на сознательность людей можно только при маленьком коллективе людей работающих в непосредственном рабочем контакте.
Я исповедую принцип, что в базу данных должно включатся только то,что реально будет использоваться на предприятии и никаких "авось пригодится": типа - занесём весь SIemens или весь Schnieder.
От корпоративных правил принятых по БД вытекают остальные решения по построению форм отчётов используемых на предприятии.

К сожалению самa компания Eplan никаких рекомендаций по данным вопросам дать не может. Видимо данные вопросы перед собой и не ставила.

NPM_P8_Rules.pdf

EPLAN_P8_Rules.pdf

[aranea]

зачем еплану со своим уставом лезть в разные монастыри? есть начальная БДИ, можно начать с ней работать, понять что к чему и дальше заполнять в нужном стиле
правила в каждой компании могут быть свои и очень отличаться друг от друга в силу специфики работы компании или возраста пользователей =)
так же как и формы и рамки: есть стандарт компании, может даже свое видение ГОСТов - все допиливается и дорабатывается по месту

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

как вы контролируете "движения материальных ценностей на предприятии" с помощью БДИ? ;)

про "авось пригодится" - один инженер рисует проект, используя выбранное оборудование например фирмы АВВ. надо автомат на 2А, он пишет заявку с указанием тех. данных (хар-ка, размеры, вид, описание) спец.обученному человеку, тот заносит его в базу, рисует макрос. дальше инженеру нужен автомат на 6А. он снова пишет заявку и ждет пока спец.человек внесет изделия от других 70 инженеров на 10-100А например.. я считаю имеет смысл вгонять в базу всю линейку при первой возможности - будет однотипно выполнен весь выбранный ассортимент

[Dyma]

На стадии создания сетевой БДИ стоял вопрос о выделении отдельного человека для работы с каталогами и занесения им изделий в базу. Но хватило ума доказать начальству, что это нецелесообразно!!!
Создана инструкция по заполнению БДИ, находящаяя в сети. Инструкция периодически пополняется, т.к. в процессе работы приходится использовать дополнительно произвольные свойства для сортировки в отчетах. Обо всех изменениях сообщается рассылкой пользователям Еплана. Если в процессе проектирования выявляется косяк в заполненном изделии (с кем не бывает :)), то исправляется нашедшим этот косяк с уведомлением создателя изделия.

[MIvanov]

Михаил, приветствую!

К сожалению до PLM/PDM и ERP систем еще не доросли. Тема актуальная. Одни грабли, сами периодически чистим БДИ. Инструкция видимо, не спасет... В Eplan-Russia мало специалистов с достаточным опытом, чтобы ответить на вопросы которые Вы задаете, да и текучка кадров я заметил...

[MBugriy]

Заполнение БД одним человеком - не вариант. Согласен с Оксаной. На скорость работы данного человека будет завязана скорость работы всех пользователей EPLAN. Один человек на такой нужной работе будет ошибаться, притом вероятно систематически. Квалифицированного человека на данную функцию не посадишь, да и никто такой нудной работы долго не выдержит. Когда говорят о "специально обученном человеке" конечно не себя имеют в виду. Не для того САПР вводится, что бы увеличивать количество специально обученных людей.

[MBugriy]

Мне сейчас видится следующий вариант:
Определяется минимум обязательных правил которые нужно непреложно соблюдать. (Заполнение полей: Обозначение1, Обозначение 2, Номер для заказа, Обозначение 3, Буквенное обозначение) всё остальное не обязательно. Каждый пользователь EPLAN должен иметь возможность внести изделие в БД соблюдая корпоративные правила применения покупных комплектующих(инструкция по заполнению БДИ, о которой говорила Оксана). Далее элемент должен пройти модерацию специалистами ответственными за этот процесс на предпреятии. Модерация БД предприятия доверяется высококвалифицированным в данном вопросе специалистам и должна занимать у них сравнительно не много времени. Должно существовать несколько уровней модерации по различным признакам, как то: срок поставки, полнота изложения технической информации, корректность заполнения определения функций, применимость для различных отчётов. наличие макросов и пр.. К примеру:
1 уровень - элемент занесён с соблюдением минимальных правил заполнения данными;
2 уровень - элемент разрешён к применению в серийных изделиях выпускаемых предприятием;
3 уровень - элемент является складской позицией на данном предприятии;
и т д.
В зависимости от требований к изделию - серийное, опытный, головной образец, можно требовать с разработчиков применение изделий с разным уровнем модерации. Разумеется и поправить изделие должен иметь возможность каждый пользователь с соответствующим снятием уровня модерации, зависимого от корректируемого поля. Для каждого проекта можно вводить специальные признаки модерации, посредством назначения которых ГИП проекта может формировать ограничительные перечни. Соблюдение принятого для проекта признака модерации должно контролироватся при здаче проекта в PDM (в архив)
Мне кажется, что разработка инструмента предмодерации корпоративной БД требуется для многих предприятий внедряющих EPLAN. Данный инструмент также может учитывать возможность импорта данных об изделии через Data Portal и включение их в основные данные предприятия. Может у кого есть идеи какими относительно простыми средствами можно наладить подобный процесс?

[MBugriy]

Мне сейчас кажется что требуется минимизировать правила занесения
элементов до текста одной страницы. Длинные инструкции никто не
читает.

Вывести общие правила заполнения для всех элементов.

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

Требовать строго соблюдать правила только по ограниченному кол-ву
полей.
Остальные поля должны заполнятся по мере того как появится
востребованность в них.
К примеру; если я хочу оперативно накидать схемку с перечнем для
коммерческого предложения Заказчику (не для изготовления), зачем мне вводить данные о
габаритах изделия, его функцию, обозначения выводов и т.п. Грамотное заполнение всех полей
это рабочее время инженера и тратить его нужно тогда когда это необходимо для
выполнения конкретной текущей задачи а не заполнять БД впрок.

Когда кому то нужен будет этот же элемент, он его найдёт и дозаполнит
нужные ему поля.
А вот что бы элемент можно было наверняка найти нужны правила на один
листок. И вывешены рядом с рабочим местом каждого пользователя EPLAN.

К примеру я сейчас выработал для себя следующие правила:

1. Запись в КД (перечень элементов, спецификация, перечень аппаратов и
пр.) любого элемента определяется слиянием через символ ", " четырёх
полей "Обозначение 1", "Обозначение 2", "Номер для заказа", "Обозначение 3"
2 "Обозначение 1" начинается с существительного и содержит наименование
изделия по его сути к примеру: Выключатель автоматический, Клемма
проходная, Блок дискретного ввода и т. д.
3) "Обозначение 2" содержит уточняющие технические характеристики
изделия и является избыточной информацией по отношению к номеру для
заказа. Данное поле должно заполнятся едентично в пределах группы
однородных изделий, выключателей, клемм, кабелей и пр. Данное поле может быть пустым, в этом случае последующий
разделитель подавляется.
4) "Номер для заказа" содержит код или другую информацию в соответствии с документацией
производителя, необходимую и достаточную для однозначного заказа
Изделия по каталогу производителя. Заполнение данного поля является обязательным.
5) "Обозначение 3" содержит наименование фирмы производителя в формате
ф."<наименование>" или обозначение документа на поставку ГОСТ или ТУ.
Заполнение данного поля является обязательным.
6) "Номер типа" заполнять желательно в качестве дополнительного
признака поиска при наличии его в каталогах производителя и при
отсутствии его в номере для заказа, данное поле может быть пустым.
7) "Буквенное обозначение" Для электротехнических изделий заполнение данного поля должно
соответствовать ГОСТ 2.710 Применение отсутствующих двухбуквенных обозначений должно быть уточнено стандартами предприятия.
Для изделия не имеющих буквенного обозначения по ГОСТ 2.710 (метизы, механика шланги
и пр.) должны быть определены специальные группы.
8) Поле "Номер для заказа" является кодом по которому будет производится
идентификация изделия в IT инфроструктуре предприятия (PDM,ERP). Оно
уникально. Его заполнение желательно автоматизировать и связать с группами устройств
определяемых буквенным обозначением.


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

[aranea]

MBugriy, вы для себя составили некоторые правила, а мне удобнее работать со следующей структурой БДИ

имхо:
п.1) а использовать большое текстовое поле "Описание" для вывода технических данных и описания любого элемента?
п.2) наименование изделия по его сути - должно быть в поле "Подгруппа продуктов", а не в "Обозначение 1" - и это недостаток Еплан, что там много чего не хватает и нет возможности добавить
п.5) название фирмы производителя указывается в поле "Производитель" или "Поставщик", а не в "Обозначение 3"
п.8) клемма UK 5 N от "Phoenix Contact" имеет заказной код (артикул) 3004362, что и можно указать в поле "Номер для заказа"

столкнувшись с ERP системой или другими нововведениями - конечно возможно придется пересмотреть свою позицию и поменять структуру БД
поэтому минимизации правил заполнения БДИ можно достичь лишь общими рекомендациями по структурированию используемой номенклатуры изделий и занесением этой структуры в базу

[MBugriy]

Александр, сколько человек работает совместно с вами по вашим правилам? Общаетесь ли вы лично со всеми пользователями БД? Когда база данных вырастет до нескольких тысяч элементов, менять структуру БД будет весьма проблематично, тем более записи уже будут использованы в проектах и под них будут сформированы отчёты. Какое поле вы выводите в отчёт "Перечень элементов", "спецификация"? Я сознательно разделил запись на четыре части что бы иметь возможность менять полноту записи в различных отчётах или выводить запись с разделением по ячейкам формы. Данные об изделии в БД , по возможности, не должны дублироваться в разных полях. "Обозначение 3" используется вместо поля "Производитель" сознательно, т.к. последним полем в записи изделий при заказе для отечественных изделий зачастую должно идти ТУ или ГОСТ.

[Автоном]

Обозначение 3" используется вместо поля "Производитель" сознательно, т.к. последним полем в записи изделий при заказе для отечественных изделий зачастую должно идти ТУ или ГОСТ.

ГОСТ или ТУ заполняется в графу "Тип, марка, обозначение документа ", а не в "Завод-изготовитель", поэтому так использоваться не может.
Мы уже почти обуздали у себя БД, но получается казус от производителей: при импорте данных от приложений таких, как ClipProject, DataPortal, конфигуратор модулей Siemens - у всех программ синтаксис написания производителей разное: SIE/Siemens/Siemens AG/SIEMENS или PhoenixContact/PHO/PXC/PHC. Итого лучший варинаты: "Siemens AG" и "PXC" - разные правила.
Приняли Номер изделие, как в DataPortal (SIE.6ES7134-4GD00-0AB0), но кабели ВВГ/КВВГ/КВВГэ не подходят под это правило -российские производители ориентируются на номер типа, а не на номер заказа (в арт.номере может не фигурировать цвет провода). Снова исключение из правил.
Так придется писать на каждого производителя правила, на каждый тип изделия правило с комментариями "Почему нельзя как у всех".
Похоже на ящик Пандоры.

[Dyma]

ГОСТ и ТУ заношу в произвольные свойства. Номер изделия заполняется аналогично вашему.
Осталась проблема с российскими проводами (например, ПВ3). Как выкручиваетесь? Прописываете цвет в "номере изделия"?

[MBugriy]

Так какое свойство вы выводите в отчёте групповой спецификации изделий, когда получаете отчёт "Перечнь элементов" или "Спецификация"? По вашему, для каждого элемента в специальные поля БД нужно писать то что хотите увидеть соответственно в перечне элементов, в спецификации, в ведомости покупных и пр. Это приводит к дублированию информации в разных полях одного и той же записи элемента БД.
Если бы можно было сформировать свойство блока для каждого изделия БД (клеммы, кабеля и пр), вопрос, в моей постановке, решался бы корректно. Но к сожалению, свойств блоков для изделий нет.

[Madwolf]

Как мне кажется, для того чтобы дискутировать неплохо бы выложить образцы отчетов, которые требуется генерировать автоматически, потому как в Еплане, на мой взгляд, сделать отчет "спецификация" по ГОСТ в принципе невозможно, т.к. в него нужно вносить и номера чертежей, т.е. этот спецификацию нужно либо собирать из частей, либо ручками делать. Поэтому спецификации могут быть разными у разных фирм.

[Dyma]

Михаил, давайте сначала определимся, на базе каких отчетов вы генерируете документы (ГСИ, СИ, список устройств).
Я делаю оба этих отчета на базе ГСИ. Только в спецификации произвольное свойтсво заносится в отдельную графу, а в ПЭ данное свойтсво входит в состав форматированного и выводится вместе с описанием изделия, номером для заказа и производителем. Никакого дублирования полей нет.

[Автоном]

ГОСТ и ТУ заношу в произвольные свойства. Номер изделия заполняется аналогично вашему.
Осталась проблема с российскими проводами (например, ПВ3). Как выкручиваетесь? Прописываете цвет в "номере изделия"?

Забил артикулы из прайса ЭКЗ по общей логике так, чтобы можно было понять по номеру с чем связано изменение номера на конце, но без комменатриев, например, "сч.пара/цифр.маркирвка/с заполнен" для КВВГ, т.к. закономерность по артикулам ЭКЗ не прослеживается, и т.п.
Поэтому ПВ3 у нас бесцветный. Снабженцы сами выбирают, это их "епархия". Но если заказ автоматизировать посредством таблицы txt, тогда по номеру для заказа на ПВ3 без цвета нам ничего не придет.
Позвонил в ЭКЗ по этому поводу, вот там и был получен ответ, что надо ориентироваться на номер типа, хотя есть почти полноценный арт.номер.

[AGorskiy]

Сегодня заменил, что на официальном сайте появилась новость, что компания анонсировала новый модуль EPLAN ERP/PDM/PLM Integration Suite, на последних семинарах в Челябинске, Тюмени, Сургуте и Нижневартовске, а завтра будет в Екатеринбурге.

Модуль EPLAN ERP/PDM/PLM Integration Suite позволяет интегрировать среду EPLAN с различными системами ERP/PDM/PLM без дорогостоящего программирования.

Это сообщение написал здесь, а не в новостях ввиду сабжа. Может у кого есть живой опыт связки Еплана и какой-нибудь PDM/TDM системы. А так же интересует ваше мнение о том, что вещали на данных семинарах, естественно в рамках существующей темы.