Lotsia PDM PLUS дает возможность реализовать самые разные информационные модели для широкого круга задач, что позволяет использовать ее для управления данными и процессами при разработке, производстве и сопровождении сложной технической продукции [1]. Данная статья посвящена некоторым общим моментам выполнения настройки, независимо от предметной области. На начальной стадии настройки системы [2] определяются основные типы объектов, атрибуты, настройки базовых справочников, групп пользователей, связей.
Адекватная реализация базовых элементов настройки нужна в первую очередь для того, чтобы не было «мучительно больно» в дальнейшем, когда развитие системы окажется затруднено в результате ошибочных решений, принятых при настройке основных элементов базы данных (БД). Рассмотрим такие случаи на конкретных примерах.
Настройка элементов структуры базы данных
В целях сохранения целостности и непротиворечивости информационной модели базовые характеристики структуры данных неизменны. Например, тип данных атрибутов не подлежит изменению штатными средствами Lotsia PDM PLUS, у созданного объекта нельзя изменить тип, атрибут проекта сделать атрибутом объекта и т.д. Поэтому правильность настройки базовых элементов структуры данных крайне важна.
А что делать, если элемент структуры все же потребовалось изменить? Стандартный путь — выдохнуть и создать новый элемент, а замененный не использовать в дальнейшем либо применить для других целей.
Типы данных атрибутов
Типичный случай — использование числового типа данных для атрибутов «Номер <чего-нибудь>». Большинство администраторов раньше или позже сталкиваются с подобной проблемой. Казалось, всегда будут числовыми входящие номера, номера разделов проектной документации, листов, объектов проектирования…
В нормативном документе может быть прямо записано — «такой-то номер — это число». Он даже может и быть числом по факту, но выявятся дробные, вполне числовые значения. И с этим можно жить, но постоянно помнить, что разделители дробной части в операционной системе на рабочей станции пользователя и в «Номере <чего-нибудь>» могут быть разными. Каждый такой случай решается настройкой, но это становится постоянной головной болью администратора — появление запятой вместо точки (или наоборот) не всегда заметно, не всегда привлечет внимание, но проявится в самый неподходящий момент. Делайте «Номера <чего-нибудь>» строковыми всегда, и вам точно не придется раздумывать, как бы ввести лист с номером, например, 23А. Или номер раздела указать в виде 2.1 — через точку.
Тип объектов и атрибуты в справочниках и в реальных проектах
Во всех настройках, как правило, применяются справочники и шаблоны, состоящие из структурированных объектов. Их использование при создании реальных данных может быть различным, в том числе копирование в создаваемые проекты или заимствование из них атрибутивной информации. Применение справочников — источник повышения производительности труда и недопущения ошибок ввода [3]. Но тут важно помнить о том, что данные, в частности изделий, должны быть легко отличимы от значений из справочников — это актуально при поиске, настройке отчетов и т.п. Поэтому не стоит использовать один и тот же тип данных для объектов в справочнике и в реальных данных. В название типа объекта в справочнике можно добавить «Справочник» или что-то похожее (рис. 1).
Рис. 1. Пример справочника из объектов специальных типов
Например, в справочнике структуры проекта «Справочник. Раздел», а в созданном проекте «Раздел». То же самое относится к атрибутам. При копировании справочников с использованием шаблонов копирования в настройках шаблона определяются замены соответствующих типов объектов и атрибутов. При выполнении указанных условий в отчетах или при поиске легко исключить из результата данные, относящиеся к справочникам. Бонусом данного подхода будет удобство настройки различных форм для справочников и реальных данных. Как правило, для объектов в справочниках и в реальных проектах требуются разные формы, что легко обеспечивается при различных типах объектов.
Управление доступом
Разграничение прав доступа и управление ими в процессе совместной работы сотрудников является одной из важнейших задач, стоящих перед администратором корпоративной информационной системы.
В первую очередь, разумеется, доступ требуется определять для групп пользователей — так им управлять гораздо эффективнее, чем на уровне отдельных пользователей. Принцип здесь следующий: корректировка (выдача и отбор) персональных прав доступа должна выполняться автоматически в рамках настроенного бизнес-процесса. В противном случае у администраторов неизбежно возникнет значительный объем ручной работы, связанный с обработкой персональных прав, которые имеют приоритет над правами групп пользователей.
Приведем некоторые «классические» примеры проблем управления доступом.
Группа «Все пользователи»
Lotsia PDM PLUS имеет богатый арсенал возможностей управления правами доступа на уровне как структуры БД, так и отдельных информационных объектов и документов.
На этапе настройки системы важно определить основные группы пользователей и необходимые им на протяжении жизненного цикла информационных объектов и проектов права доступа.
Так вот, если сотрудникам организации принять соответствие штатной группы «Все пользователи», будет легко управлять доступом сотрудников, тем более что в группу «Все пользователи» каждый новый пользователь входит автоматически.
Но представим себе ситуацию, когда по мере развития системы в число пользователей включается всё больший круг лиц. Это могут быть практически посторонние люди: сотрудники хозяйственных и вспомогательных подразделений, партнеры, заказчики. И вот тут наличие действующих прав доступа для группы «Все пользователи» может стать мучительной проблемой. Дело в том, что отобрать права у пользователей, получивших их от данной группы, можно только заданием персональных прав, либо прав для групп, в которые должны гарантированно войти все пользователи. И то и другое нежелательно само по себе, так как в принципе добавит работы администратору и может послужить источником ошибок. Кроме того, когда на определенном этапе развития системы возникнет потребность ограничить автоматическое предоставление разрешающих прав новым пользователям, понадобится дополнительная срочная работа по одномоментному перераспределению доступа к имеющимся данным. При большом объеме данных это может стать проблематичным.
Чтобы изначально не допустить подобного, не стоит необдуманно использовать группу «Все пользователи» для выдачи прав. Поможет создание отдельных групп, назовем их условно «Сотрудники», куда добавляемых пользователей включает администратор. При соответствующей настройке инструментов добавления нового сотрудника в систему это не усложнит работу администратора, зато в дальнейшем предотвратит появление проблем, которые можно было предусмотреть. При таком подходе добавленный в систему новый пользователь гарантированно не получит доступа к защищенной информации иначе, чем определил администратор.
Управление составами групп, а не правами
Управлять правами можно по-разному, трудоемкость и эффективность тоже будет различная. В любом случае стоит стремиться к минимизации прав, установленных на конкретном объекте. Зачастую различным пользователям требуется выдать одинаковый набор прав. Стандартная ситуация: разработчики проекта должны иметь возможность его редактирования, причем состав разработчиков может изменяться. После утверждения проекта его редактирование должно быть запрещено, а в случае внесения изменений редактирование вновь временно разрешается ограниченному кругу лиц. Сам проект обычно имеет достаточно сложную структуру и состоит из большого числа объектов.
Хотя Lotsia PDM PLUS обладает широкими возможностями для управления правами, в том числе автоматического наследования (распространения) выданных прав на связанные объекты, использования шаблонов прав и так далее, в ряде случаев само управление правами можно заменить на управление составами групп пользователей. Для таких групп сразу задается требуемый набор прав, который в дальнейшем может не меняться. Такой подход оказывается гораздо более эффективным, так как, в конечном счете, не требует редактирования прав доступа на отдельные объекты, а изменение прав членов группы происходит мгновенно. При создании проектов обычно используются макрокоманды, где может быть настроено и автоматическое создание требуемых типовых групп пользователей (например, для каждого проекта или элемента его состава) с выдачей этим группам требуемых прав. Состав групп формируется автоматически, по мере определения исполнителей, смены стадии разработки и в зависимости от других условий.
Некоторые группы удобно делать скрытыми (рис. 2), чтобы не засорять списки групп, которыми необходимо управлять вручную.
Рис. 2. Скрытые группы пользователей
Чтобы исключить возможность редактирования утвержденного проекта, достаточно будет очистить соответствующую группу от пользователей, а для внесения изменений — добавить в группу сотрудников, уполномоченных внести изменения, с автоматическим исключением их после проведения изменений. При этом во многих случаях полностью отпадает необходимость управления правами на уровне экземпляров данных! Всё это технически не сложно реализовать, если предусмотреть использование соответствующих групп в рамках каждого проекта.
Об организации данных
При всем многообразии моделей данных, реализуемых средствами Lotsia PDM PLUS, остановимся еще на некоторых общих моментах, которые также необходимо учитывать при разработке модели данных.
Множественная входимость
Для машиностроения, приборостроения и т.п. заимствование изделий и составных частей — стандартная практика, и применение множественной входимости, как правило, происходит «само собой». При добавлении готовых составных частей в разрабатываемое изделие эти составные части включаются в состав очередного изделия с указанием для каждого использования некоторой собственной информации. Например, количества заимствованных элементов, позиции на сборочном чертеже и т.п. В терминологии Lotsia PDM PLUS это создание новых связей между родительскими и заимствуемыми изделиями и добавление соответствующих «атрибутов проекта» (атрибутов связи).
Бонусами такого подхода является компактное хранение информации (отсутствие лишнего копирования), удобство управления изменениями (изменение заимствованного элемента автоматически отображается для всех случаев заимствования), а также для любого элемента автоматически прослеживаются все случаи его заимствования (применяемости).
Для проектных организаций применение множественной входимости не так очевидно — документ проекта является неотъемлемой частью того комплекта, в рамках которого он разработан. Однако имеются и комплекты-сборники, куда включается как собственная документация, так и заимствованные из других комплектов документы. И тут для документов, разработанных в других комплектах, использование множественной входимости (вместо создания копий документов) оказывается весьма кстати. Бонусы, получаемые при таком подходе, те же самые. Разумеется, требуется исключить редактирование заимствованных документов в рамках сборников, но это типовая задача, решаемая независимо от копирования или заимствования. Для машиностроения исключение редактирования заимствованных элементов в ходе разработки также актуально.
Бывают ситуации, когда множественную входимость требуется «прекратить». Например, когда от разработки изделия мы переходим к его массовому выпуску, хотим сохранить информацию о каждом выпущенном экземпляре изделия и его дальнейшей судьбе — эксплуатации, обслуживании, ремонтах, утилизации. В этом случае при производстве экземпляра изделия его состав фиксируется с помощью копирования по специальному шаблону, но с некоторыми особенностями.
Весь состав изделия с документацией и полным набором составных частей «до последнего гвоздя» копировать и отдельно хранить обычно нет необходимости. То есть при копировании требуется фильтровать состав и ограничивать глубину вложенности. Тем не менее, если в составе изделия несколько раз встречается учитываемый составной элемент, то все его заимствования должны храниться в виде отдельных экземпляров информационных объектов со своим атрибутивным наполнением, таким как серийный номер, отметка о принятии ОТК и т.д. В результате мы сможем в дальнейшем отследить судьбу каждого такого элемента — наработку, ремонты, перестановки на другие изделия и т.п.
В Lotsia PDM PLUS настройки такого копирования в основном сводятся к установке требуемых параметров применяемого шаблона копирования (рис. 3).
Рис. 3. Настройка шаблона копирования для «прекращения» заимствования
По возможности старайтесь использовать множественную входимость. Как правило, это дает хороший результат, а потенциальные трудности преодолимы.
Наследование атрибутов
При разработке модели данных желательно изначально понимать, какие выборки информационных объектов вам понадобится получать в дальнейшем. Например, для проектных организаций обычно требуется отбор по проекту, по главному инженеру проекта (ГИПу) и др.
Независимо от предметной области типовыми являются отбор по способу финансирования, номеру в программе работ, теме, заказчику, договору, платежному этапу и т.д. Для облегчения и ускорения отбора по подобным параметрам можно применять специальные атрибуты, автоматически присваиваемые создаваемым экземплярам объектов. Такие атрибуты обычно «наследуются» (копируются) с родительского объекта при создании очередного дочернего. В качестве значения такого атрибута может использоваться или само значение (например, обозначение проекта) или идентификатор (ID) соответствующего объекта (ГИПа в структуре предприятия, договора, заказчика в справочнике контрагентов и т.д.), или даже оба значения сразу, к примеру, «ID заказчика» и «Наименование заказчика». При этом трудоемкость создания объектов заметно не изменяется, а вот отобрать объекты по требуемым критериям становится гораздо проще и удобнее. Это может значительно облегчить выполнение различных обработок, заполнение пользовательских форм и формирование отчетов.
Кроме атрибутов информационных объектов для целей систематизации сообщений, автоматически генерируемых в рамках бизнес-процессов, можно создавать атрибуты карт работ. При выполнении процессов, например выдаче заданий, согласовании документов и т.п., можно автоматически устанавливать данные атрибуты всем сообщениям данного процесса, а впоследствии использовать их как колонки в настройке почтовых папок пользователей — для фильтрации и отбора по ним сообщений (рис. 4).
Рис. 4. Настройка колонок для сообщений пользователей
Зачастую наследование атрибутов заметно облегчает жизнь и администратору, и конечному пользователю системы. Но не следует забывать, что, например, ГИП может меняться. То есть вам придется предусмотреть случаи, когда замену атрибута у большого количества объектов потребуется выполнять на регулярной основе. Главное, чтобы такая процедура была заранее реализована и протестирована, иначе польза от наличия подобного атрибута сведется к нулю.
Заключение
Как показывает практика, следование простым рекомендациям, приведенным выше, существенно сокращает временные и финансовые затраты на внедрение и сопровождение системы, а также радикально повышает качество данных. Сочетание этих решений с примерами из лучших практик, предоставляемых компанией «Лоция Софтвэа» пользователям системы Lotsia PDM PLUS, позволяет в кратчайшие сроки внедрить в масштабах предприятия эффективное решение по управлению информацией о продукции на протяжении всего ее жизненного цикла.
Литература:
- Садовников Д.Л., Ширяев Н.В. Использование Lotsia PDM PLUS 6.10 для управления данными и процессами предприятия при разработке сложных проектов и продукции / Садовников Д.Л. и др. // САПР и графика. 2024. № 9. С. 6-13. ISSN 1560-4640.
- Садовников Д.Л. О настройке Lotsia PDM PLUS / Садовников Д.Л. // САПР и графика. 2021. № 3. С. 60-67. ISSN 1560-4640.
- Садовников Д.Л. Контроль действий пользователей при реализации процессов информационного моделирования / Садовников Д.Л. // САПР и графика. 2024. № 11. С. 51-55. ISSN 1560-4640.
