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

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

Из чего же мы выбираем?

1. Уровень системы

2. Архитектура системы

3. Организация хранения информации

4. Разграничение прав доступа

5. Полнота русификации

6. Наличие реальной технической поддержки в регионах

7. Соответствие требованиям отечественных стандартов

8. Возможность настройки системы под требования заказчика

9. Легкость адаптации и простота освоения системы персоналом заказчика

10. Стоимость приобретения, внедрения и сопровождения

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

Так какую же систему из имеющихся на рынке выбрать? Ответ очевиден: ту, которая наиболее эффективно сможет решать задачи предприятий, как в настоящий момент, так и в перспективе.

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

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

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

Из чего же мы выбираем?

Прежде всего давайте определимся, что представляют собой системы TDM (Technical Document Management) и PDM (Product Data Management). Как видно из самих названий, системы TDM являются документно-ориентированными и модель их данных строится на составе документации. Соответственно системы PDM базируются на составе изделия (объекта).

Уже на основании этих данных вы можете сделать вывод о том, к какому классу относится рассматриваемая система. В любом случае, для общего ознакомления с информацией о PDM-системах настоятельно рекомендуем посетить Web-сайты консалтинговой компании CIMdata (http://www.cimdata.com/) и информационного центра по PDM (http://www.pdmic.com/). Это позволит определить хотя бы установочные ориентиры при выборе системы. Разумеется, вся информация, представленная на этих серверах, приводится на английском языке. И практически все описываемые системы (за редким исключением) — зарубежной разработки. Но в ближайшее время начнет работать и российский сайт по PDM-системам (http://www.pdm.ru/).

И вот вы ознакомились с базовой информацией по системам PDM — и пребываете в легком недоумении. Оказывается, помимо собственно систем PDM есть и системы cPDm (Collaborative Product Definition Management), и системы cPLM (Collaborative Product Lifecycle Management). Неужели все так страшно? Отнюдь нет. Если отбросить все маркетинговые изыски, то данные формулировки описывают всего лишь выход систем PDM на новый уровень: управление всеми данными о продукции на протяжении всего жизненного цикла при совместной работе больших групп пользователей разных профилей.

Получив первичное представление о системах TDM/PDM, попробуем выработать критерии сравнения. Но нужно ли вообще их сравнивать?

На одной из прошедших в конце 2001 года конференций мне довелось услышать в кулуарах, что «сегодня систем TDM/PDM на рынке — как грязи, все они примерно одинаковые, и можно выбирать любую». А в одной из статей журнала «САПР и графика» («Миф под названием Windchill», № 11’2001) по поводу двух систем PDM говорится буквально следующее: «сравнивать их по набору базовой функциональности мы не будем». Правильный ли это подход? На наш взгляд, нет, поскольку потребности заказчиков могут коренным образом различаться в зависимости от профиля предприятия и спектра задач, решаемых с помощью системы. Совсем не обязательно, что система, прекрасно адаптированная для решения задач в области машиностроения, будет столь же успешно применяться, например, в проектных организациях.

Итак, переходим к определению критериев.

1. Уровень системы

По функциональным возможностям и максимально допустимому количеству одновременно работающих пользователей системы TDM/PDM можно разделить на следующие типы:

1. Системы масштаба подразделения (приблизительно до 30-50 одновременно работающих пользователей).
2. Системы масштаба предприятия (приблизительно от 100 до 5000 одновременно работающих пользователей).
3. Системы масштаба корпорации (приблизительно от 100 до десятков тысяч одновременно работающих пользователей, с обязательной поддержкой территориально-распределенного режима работы).

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

Следует внимательно отнестись к функциональным возможностям системы. Фактически современные системы PDM состоят из следующих модулей:

• хранилище объектов и средства управления документами (Data Vault и Document Management);
• средства управления структурой изделия (Product Structure Management);
• средства поддержки классификаторов и справочников (Classification);
• средства просмотра и аннотирования документов и моделей различных форматов (View & Redlining);
• средства управления проектом и проведением изменений (Workflow и Process Management);
• средства поиска информации;
• средства управления проектом;
• интерфейсы к прикладным пакетам (прежде всего к САПР);
• коммуникационные интерфейсы и интерфейсы к АСУП;
• интерфейсы прикладного программирования и трансляторы.

Соответствие приведенным выше требованиям и определяет в первую очередь принадлежность системы к тому или иному классу. Большую роль здесь играет архитектура систем и используемые ими СУБД (практически все современные системы используют какую-либо СУБД для хранения и поиска информации).

2. Архитектура системы

Представленные сегодня на рынке системы делятся по типу используемой ими архитектуры (в соответствии с используемыми ими СУБД и принципами работы) на файл-серверные (большинство систем для рабочих групп) и клиент-серверные (2- и 3-уровневые). Наряду с этим можно выделить так называемые Web-ориентированные системы, но они, как правило, тоже используют какую-либо СУБД.

Целесообразность использования систем, разработанных в файл-серверной архитектуре, ограничивается «сверху» 20-30 одновременно работающими сотрудниками. При большем количестве одновременно работающих сотрудников возможно резкое снижение производительности. Кроме того, такие системы не обеспечивают необходимой отказоустойчивости и защиты данных от несанкционированного доступа. Поэтому, если мы видим, что приложение использует, например, базы данных Paradox, мы можем сразу же отказаться от его использования в масштабе крупного предприятия.

Для систем масштаба предприятия более подходят СУБД, построенные в клиент-серверной архитектуре. Но означает ли использование программой СУБД Interbase или даже Oracle то, что система может быть действительно эффективна при одновременной работе сотен пользователей? К сожалению, не всегда. Во-первых, все SQL-серверы имеют разные предельные возможности по одновременной работе пользователей и различную производительность. Во-вторых, использование даже самой лучшей и высокопроизводительной СУБД может не дать положительного результата, если разработчик не имеет опыта создания и внедрения систем, работающих с большими объемами данных («запорожец» с двигателем от «мерседеса» — еще не «мерседес»).

Следующий вопрос, который возникает у пользователей: какие именно СУБД поддерживает данная система? Желательно, чтобы выбранная вами система поддерживала ту СУБД, которая имеется на вашем предприятии, чтобы не «разводить зоопарк». Очевидно, что чем больше СУБД поддерживает система, тем она предпочтительнее. Но большая универсальность, как правило, достигается в ущерб производительности. Так что выбор здесь — за заказчиком, которому остается довериться опыту компании-разработчика.

К сожалению, иногда даже в серьезных изданиях можно встретить совершенно безответственные утверждения фирм-разработчиков. Например, в статье «AdemVault — электронный архив CAD/CAM АDEM» («САПР и графика» № 10’2001) можно найти следующие заверения авторов одной из систем: «В качестве системы управления базами данных можно использовать любую из существующих». Данное утверждение свидетельствует либо о недостаточном опыте разработчиков, либо о желании ввести потенциальных заказчиков в заблуждение. Система, написанная, например, для MS SQL Server, далеко не всегда будет работать с СУБД Sybase или Oracle.

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

3. Организация хранения информации

Как правило, системы TDM/TDM используют схему раздельного хранения информации: данные о структуре изделия, свойствах (атрибутах объектов), сведения о правах доступа и другие метаданные хранятся в базе данных (database), а собственно тела документов (файлы) — в оригинальных форматах в защищенных хранилищах на файловых серверах (Vault). По этой схеме построено более 90% представленных на мировом рынке систем и практически все лидирующие решения.

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

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

4. Разграничение прав доступа

к информации и защита документов в системе

Надежная защита данных является обязательным требованием к системе. Защищаются как объекты (документы, изделия и т.п.), так и связанные с ними метаданные.

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

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

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

5. Полнота русификации

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

В системе обязательно должны быть реализованы корректные поиск (в идеале — с учетом морфологии) и сортировка слов на русском языке. Также должно обеспечиваться правильное отображение букв кириллицы в документах различных форматов в разных кодировках (чертежи AutoCAD многочисленных версий, текстовые документы MS Word и т.д.) и поддерживаться работа с документами, имеющими длинные имена файлов на русском языке.

6. Наличие реальной технической поддержки в регионах

Одним из обязательных условий успешного внедрения является тесное взаимодействие пользователя с поставщиком системы. Если весь штат офиса компании-разработчика состоит из директора, менеджера по продажам и секретаря, а за поддержкой предлагается обращаться в США (Англию, Германию и т.п.) — это не будет способствовать быстрому решению разного рода проблем, которые неизбежно возникнут на начальном этапе внедрения.

7. Соответствие требованиям отечественных стандартов

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

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

8. Возможность настройки системы под требования заказчика

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

В настоящий момент на рынке имеются системы, которые поставляются вообще без предварительных настроек (просто как универсальное ядро). Очевидно, что приобретение подобной системы выльется в дополнительные временные и финансовые затраты при ее внедрении.

Но подробнее о базовых функциональных возможностях систем TDM/PDM мы поговорим в следующих номерах.

9. Легкость адаптации и простота освоения системы персоналом заказчика

В зарубежной технической литературе широко используется термин «usability», который можно перевести как «удобство использования». Для систем TDM/PDM (как и для других корпоративных систем) необходимо различать простоту в администрировании при настройке системы и удобство работы конечных пользователей с уже настроенной системой.

Таким образом, первое, на что нужно обращать внимание, — насколько просто можно настроить систему. Предпочтение здесь должно отдаваться системам, включающим визуальные средства настройки и не требующим программирования. Сейчас же на мировом и российском рынке представлены совсем не дешевые системы, любая (!) настройка которых должна сопровождаться программированием на Java или C/С++ и т.п.

Например, представители одной из компаний-разработчиков пишут, что только для выполнения простой настройки подключения системы к уже существующей базе данных заказчика информации «достаточно 1-2 дней работы программиста невысокой квалификации» («Некоторые вопросы внедрения TDM/PDM-систем», «САПР и графика» № 11’2001). При этом предполагается наличие у заказчика специалистов по программированию на конкретном (!) языке. (Для сравнения: в ряде других систем это делается без программирования максимум за пару часов.)

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

10. Стоимость приобретения, внедрения и сопровождения

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

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

Во-первых, тип лицензий, предлагаемых заказчику. Очевидно, что конкурентные (плавающие) лицензии более выгодны заказчику, нежели именованные.

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

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

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

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

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

Автор будет благодарен за участие в дополнении и развитии этого списка. В конце концов, это в наших общих интересах.

Окончание следует

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