Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557

Рекламодатель: ООО «ЛС-Технологии»

ИНН 7807258360 ОГРН 1227800102375

Рекламодатель:
ООО «С3Д Лабс»

ИНН 7715938849 ОГРН 1127747049209

2 - 2002

Критерии сравнения систем TDM/PDM

Николай Ширяев

11. Интеграция TDM/PDM с прикладными системами

12. Территориально распределенный режим работы

13. Поддержка стандартов

14. Функциональность

   14.1. Упорядоченное хранение документации

   14.2. Время поиска документов

   14.3. Организация архива

   14.4. Возможности по изменению модели данных системы и интерфейса

   14.5. Работа с проектами и организация документов и объектов в логические папки

   14.6. Возможности системы по протоколированию и регистрация изменений документов

   14.7. Возможности системы по экспорту-импорту информации (базы данных и документов)

   14.8. Быстрый просмотр документов и моделей

   14.9. Возможности по выполнению групповых операций

   14.10. Функциональность в области управления информацией об изделии и проектными данными

   14.11. Требования к средствам документооборота и контроля исполнения

Мы публикуем окончание статьи Николая Ширяева (см.«САПР и графика» № 1’2002), в которой

представлен перечень критериев сравнения TDM/PDM-систем.

Цель данной статьи — попытаться выработать некий минимальный набор критериев для объективного сравнения и оценки систем TDM/PDM, чтобы помочь заказчику выбрать оптимальное для него решение.

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

Итак, продолжаем перечисление критериев сравнения.

11. Интеграция TDM/PDM с прикладными системами

Говоря об интеграции TDM/PDM-систем с прикладным программным обеспечением, мы в первую очередь вспоминаем о различных САПР. Это правильно, но не следует забывать и об интеграции с офисными приложениями, АСУП и другими программами, используемыми на предприятии.

Можно выделить несколько уровней интеграции с приложениями:

  • возможность хранения в системе документов (файлов), созданных в других приложениях, или ссылок на них. Это минимальный уровень интеграции, поддерживаемый большинством систем;
  • обмен данными между полями документа (например, штампом чертежа) и атрибутивной информацией, хранящейся в базе данных системы PDM. Это позволяет избежать повторного ввода информации пользователем;
  • передача информации о параметрах модели в систему PDM с синхронизацией данных в автоматическом или ручном режиме;
  • корректная работа с компонентными (многофайловыми) документами и с документами, содержащими ссылки на другие документы (XREF-файлы и т.д.).

Очевидно, что различные программы обеспечивают разный уровень интеграции.

В начало В начало

12. Территориально распределенный режим работы

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

Реализовано это может быть такими способами:

  • собственно работа в сетевом режиме в рамках WAN (Wide Area Network);
  • работа в режиме удаленного доступа (обычно используется для подключения небольшого количества удаленных пользователей), например с использованием RAS (Remote Access Server);
  • работа через сеть Internet (или Intranet) с тонким клиентом. Эта очень популярная схема работы в последнее время подвергается критике по соображениям защиты данных (напомним, что Пентагон принял решение о создании собственной сети, никак не связанной с Internet);
  • работа через защищенные частные сети (VPN);
  • работа мобильных пользователей;
  • работа с репликацией данных при использовании одного из описанных выше способов связи или даже при обмене информацией в режиме off-line (на съемных носителях, по электронной почте и т.п.).

Практически любая из указанных схем позволяет работать с территориально распределенными базами данных (в зависимости от используемой СУБД).

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

В начало В начало

13. Поддержка стандартов

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

Применительно к системам PDM/TDM учет требований российских стандартов (ЕСКД, ЕСТД, СПДС и др.) означает прежде всего возможность получения стандартных форм отчетных документов (спецификации, ведомости и т.п.) и автоматизацию процессов разработки, а также утверждения и изменения изделия и документации на него.

При этом нужно понимать, что BOM (Bill Of Material) — далеко не то же самое, что отечественная спецификация по ГОСТ, как ни пытаются убедить в обратном некоторые поставщики зарубежных систем.

Наиболее известными зарубежными стандартами, используемыми в области PDM, являются ISO 10303 (STEP) — универсальный стандарт по обмену данными и стандарты серии ISO 9000 — стандарты обеспечения качества.

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

В области интеграции прикладных программ с системами TDM/PDM в качестве стандарта все чаще используется ODMA (Open Document Management API). Поддержка ODMA позволяет приложению взаимодействовать с множеством других программ.

Для систем Workflow и модулей Workflow систем PDM/TDM роль такого практически обязательного стандарта играют рекомендации WfMC (Workflow Management Coalition).

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

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

Перейдем к определению критериев сравнения функциональности программ.

В начало В начало

14. Функциональность

14.1. Упорядоченное хранение документации

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

При этом могут быть использованы следующие методы поиска:

  • по атрибутам;
  • ключевым словам;
  • содержанию документа (полнотекстовый поиск), включая поиск с частичным совпадением (нечеткий поиск). Разумеется, здесь речь идет об использовании специализированных средств полнотекстовой индексации документа. Важно знать, какие форматы документов поддерживает индексатор и как он работает с документами на русском языке;
  • битовым маскам (наиболее часто используется для поиска растровых изображений);
  • топологии объекта;
  • геометрической модели (обычно используется только для моделей, полностью спроектированных в САПР, разработанной поставщиком системы PDM).

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

Обязательному сравнению подлежит и возможность строить произвольные сложные запросы и сохранять результаты запросов для повторного обращения к ним.

В начало В начало

14.2. Время поиска документов

Сравнение систем по данному критерию во многом сводится к сравнению используемой архитектуры и СУБД, но результаты его во многом определяют реальную возможность использования системы. Необходимо, чтобы система обеспечивала достаточные характеристики по среднему и максимальному времени поиска документов — как хранящихся в оперативном или динамическом архиве, так и для документов архива долговременного хранения или статического архива.

В начало В начало

14.3. Организация архива

Здесь имеются в виду возможность организации централизованного и децентрализованного хранения документов; реализация разграничения прав доступа — как для каждого логического архива документов, так и для каждого документа в логическом архиве.

Кроме того, сравниваются возможности создания версий и подверсий документов. Имеются ли ограничения по количеству версий документа?

В начало В начало

14.4. Возможности по изменению модели данных системы и интерфейса

Следует выяснить, можно ли создавать пользовательские типы объектов, задавать для них новые характеристики (атрибуты), логические связи и бизнес-логику; каковы возможности системы по модификации интерфейса для разных групп пользователей.

Понятно, что все это определяет гибкость системы.

В начало В начало

14.5. Работа с проектами и организация документов и объектов в логические папки

Анализируются возможности системы по организации документов в проекты (логические папки) без физического перемещения или копирования документов.

Существуют ли ограничения на сложность и глубину вложенности проектов?

Имеется ли возможность просмотра полной применяемости в различных проектах, а для проектов — просмотра состава и связей с другими проектами?

В начало В начало

14.6. Возможности системы по протоколированию и регистрация изменений документов

Как обеспечивается отслеживание действий пользователей и изменений документов? Какая информация при этом сохраняется и в каком виде? Наличие данных функций тесно связано с соблюдением требований стандартов серии ISO 9000.

В начало В начало

14.7. Возможности системы по экспорту-импорту информации (базы данных и документов)

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

Все эти возможности определяют, насколько легко система может использовать уже имеющиеся унаследованные данные, а это влияет на время ввода системы в эксплуатацию.

В начало В начало

14.8. Быстрый просмотр документов и моделей

Входят ли в состав системы средства для быстрого просмотра моделей, чертежей и других документов? (Здесь необходимо отметить, что, несмотря на множество бесплатных средств просмотра, большинство крупных производителей систем TDM/PDM предпочитают лицензировать специализированные мультиформатные вьюеры, которые обеспечивают поддержку максимального количества форматов.) Поддерживает ли вьюер русские шрифты? (Имейте в виду, что особенно часто проблемы с отображением русских букв возникают при просмотре чертежей, выполненных в ранних версиях AutoCAD).

Поддерживаются ли просмотр трехмерной модели сборки и навигация по ней? Требуется ли для этого, чтобы сборка была целиком спроектирована в рамках одной системы? (Ряд производителей систем TDM/PDM декларируют возможность по работе со сборками, отдельные детали которых спроектированы с использованием разных САПР, однако работает это далеко не всегда.)

Имеются ли средства аннотирования чертежей и трехмерных моделей? Какие форматы поддерживаются для аннотирования?

Имеется ли возможность сравнения чертежей?

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

В начало В начало

14.9. Возможности по выполнению групповых операций

Включает ли система функции по работе с группами объектов: изменение значения атрибутивной информации, внесение новой информации и др.?

В начало В начало

14.10. Функциональность в области управления информацией об изделии и проектными данными

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

Приведем краткий перечень основных критериев сравнения систем по этим показателям:

  • поддержка неограниченной глубины уровней структуры изделия неограниченной сложности;
  • возможности многовариантного проектирования. Возможности хранения вариантов, не вошедших в основной проект;
  • работа с исполнениями и конфигурациями изделий. Возможности формирования обозначения исполнений в автоматическом режиме в соответствии с требованиями ЕСКД;
  • возможность создания проекта на основе существующего;
  • наличие средств визуального сравнения двух и более проектов;
  • возможности получения информации о вхождениях объекта в проекты;
  • возможности классификации узлов, деталей и документов. Возможность формировать обозначение из классификатора или в автоматическом режиме. Возможность формирования обозначений в соответствии с требованиями ЕСКД, СПДС и другими отечественными стандартами. Возможности контроля неповторяемости обозначений;
  • наличие функций учета изменений;
  • возможности системы по генерированию на любой стадии проекта различных отчетов. Возможность формировать спецификации и различные ведомости по ЕСКД, СПДС и стандартам предприятия;
  • возможности по ведению истории создания изделия;
  • наличие средств для формирования специализированных режимов представления информации о проекте для различных групп сотрудников.
В начало В начало

14.11. Требования к средствам документооборота и контроля исполнения

Как уже было сказано, в области Workflow большинство серьезных разработчиков ориентируются на требования WfMC (http://www.wfmc.org/). Членами WfMC являются такие известные компании, как IBM, Microsoft, SAP AG, Parametric Technology Corp (PTC), Documentum, Staffware и многие другие.

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

Упрощенно критерии сравнения Workflow-возможностей систем TDM/PDM можно представить в виде следующих вопросов:

  • возможна ли маршрутизация как отдельных документов, так и групп документов, а также работ и сообщений;
  • поддерживает ли система свободную, предопределенную и комбинированную маршрутизацию;
  • возможна ли рассылка сообщений и извещений (Messages and notifications);
  • поддерживается ли иерархическая структура организации;
  • имеется ли интеграция средств Workflow с системами групповой работы и электронной почты MS Exchange, Lotus Notes и т.д.;
  • обеспечивается ли возможность задания абсолютных (календарных) и относительных сроков работ;
  • предусмотрено ли визуальное графическое представление (создание и редактирование) маршрутов/заданий при предопределенной маршрутизации;
  • имеется ли возможность назначать аудиторов (сотрудников с административными полномочиями) на работы или маршруты прохождения документов;
  • может ли инициатор работы или аудитор получить в любой момент справку о состоянии (статусе) работы или документа;
  • каковы возможности по созданию сложных работ (переход по условиям, циклы и т.д.) Без наличия возможностей построения сложных схем бизнес-процессов практически невозможно автоматизировать, например, проведение изменений.

Итак, мы выработали краткий перечень критериев сравнения систем TDM/PDM. В зависимости от конкретной специфики предприятия этот перечень может быть изменен. Также очевидно, что разные критерии могут иметь при выборе системы для конкретной организации различную значимость.

Автор предлагает читателям журнала «САПР и графика» совместно с редакцией и представителями фирм-разработчиков дополнить и развить данный перечень критериев оценки, чтобы выработать своеобразный «набор эталонных тестов» для систем TDM/PDM. 

«САПР и графика» 2'2002

Регистрация | Войти

Мы в телеграм:

Рекламодатель:
ООО «Нанософт разработка»

ИНН 7751031421 ОГРН 5167746333838

Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557