Название Журналов Изменений

[CherryMan]

Приветствую Вас!

Прошу поделиться опытом тех, кто в своей деятельности сталкивался с модулем ЛОЦМАН: PLM "Журнал изменений".
Мы используем Лоцман версии 2013 сп2. Начинаем внедрять сей модуль, и вот не можем никак определиться как же называть те самые объекты типа "Журнал изменений".
1. Привязывать к названию изделий, например "ЖИ-Изделие №2" нам не подходит, потому как многие детали и узлы могут применяться и в других изделиях.
2. Привязывать к дате создания, например "ЖИ-Август 2015" или "ЖИ- I квартал 2015" так же не комильфо. Так как проблема может возникнуть и в 2016 и в последующих годах.
3. Привязывать к децимальному номеру, например "АБВ7.***.***" или "АБВ2.000.000" также не тянет на позитивные мысли, особенно если представить сколько таких децималей и соответствующих изменений будет в этом журнале.

Посему прошу Вас, поделитесь опытом.

P.S. Привет из Сибири, из КРСКа

[Danila]

Могу рассказать, как организовано у нас.

Мы не используем никакие модули.

Для каждого изделия, или соответствующей группы изделий создается объект типа "Журнал изменений".
Каждому следующему журналу автоматически присваивается с помощью автонумератора следующий номер. Информацию по принадлежности журнала к изделию заполняет разработчик в карточке Журнала.

В дереве Лоцмана настроено отображение так, чтобы отображался номер журнала и изделие.

Далее создаются записи - это документы типа "Запись журнала изменений". Которым автоматически присваиваются номера вида хххх-уу, где уу - номер журнала, к которому они принадлежат, хххх - порядковый номер внутри журнала, присваиваемый автоматически.

Разработчик записи подробно заполняет карточку Записи - таким образом оформляет все необходимые поля. И закладвает соответствующие файлы.

Записи журнала организационно требуется привязывать по связи "Уточняет" ко всем документам, к которым она относится.

Затем мы уже с помощью своего модуля извещений организовали так, что при втягивании записи в извещение, вводятся в извещение и связанные с записью документы. И наоборот при документе вводятся записи, которые выберет разработчик. При проведении извещения - запись автоматически гасится.

[CherryMan]

Спасибо за отзывчивость!
Схожую схему мы планировали ранее. Однако нам требуется по данному журналу утверждать новые документы и корректировать сданные в архив документы. Причем непосредственно коррекция по ЖИ в архив не ложится, документация сдается в архив только лишь после выпуска "Извещения об изменении".

У нас на предприятии опытные образцы сразу запускаются в производство. Для этого надо побыстрее "утвердить" документацию, чтобы отдать в цеха. Условный "Ведущий конструктор изделия" имеет право утвердить документацию, после чего, когда в цехе обнаружится "косяк",  конструктор быстро (без проверки технологами, нормоконтролёрами) создает последущую версию и проводит сие изменение через ЖИ.
После того как все "косяки" исправлены - документация отправляется на тчательные проверки технологам и нормоконтролёрам, и сдается в архив.

Руководство требует использовать именно базовые модули Лоцмана

[Danila]

Фактически мы и использовали базовый основной механизм Лоцмана.
Создание объектов выполняется с помощью стандартных механизмов. Заполнение карточек - также.
Автонумератор системой "Лоцман" поддерживается в том или ином виде, хотя мы и используем свой механизм - в системе "Лоцман" есть стандартный аналог.

Модуль извещений - это да, отдельная история. Но не обязательно выполнять автоприсоединение. И то, что делаем мы. Может, вам это не нужно.

Вопрос закладки КД и ТД в какой момент - определяется стандартами вашего предприятия.
Мы также не размещаем саму документацию по ЖИ в архив, она по связи устанавливается к тем нашим архивным версиям, по которым запущен процесс производства изделия. Это делается чтобы информировать о необходимости доработок КД, ТД и доработок в производстве - оперативная коррекция.

Стандартными механизмами все потребности предприятия не всегда реализуешь - это факт. Коробочная версия - не совсем универсальна и под каждое решение не может быть тонко настроена без каких-либо доработок на том или ином уровне. Потому требования вашего руководства исходят только из "хотелок", а не из здравого смысла.

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

И скорее систему надо настраивать под предприятие и стандарты, а не наоборот. Конечно, с учетом возможностей системы и возможностей ее изменения и ее поддержки.