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

ИНН 7726601967 ОГРН 1087746953557

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

ИНН 7715938849 ОГРН 1127747049209

11 - 2007

Популярно о концепции развития настройки в Lotsia PDM PLUS

Виктор Афанасьев, Дмитрий Садовников

Программа Lotsia PDM PLUS — это не просто обычное PDM-решение для машиностроения или проектных организаций. Ее возможности по применению в различных отраслях гораздо шире. Можно даже сказать, что это своеобразный конструктор, позволяющий настроить процедуры учета и управления любой информацией независимо от предметной области, то есть от профиля деятельности предприятия. Уже более 10 лет Lotsia PDM PLUS успешно внедряется в различных отраслях, и, вероятно, ни один производитель систем класса PDM/TDM/Workflow не может похвастаться столь масштабным распространением своего продукта на постсоветском пространстве: Lotsia PDM PLUS в той или иной мере используется более чем на 500 предприятиях из 27 отраслей.

Как же использовать гибкость системы с максимальной отдачей? Попробуем просто и с приведением примеров изложить концепцию настройки Lotsia PDM PLUS от описания модели данных до настроек, упрощающих интерфейс конечного пользователя.

Первые шаги по регистрации таких элементов структуры базы данных, как типы объектов и атрибуты сложности не вызывают и преследуют единственную, но очень важную цель — описать модель данных. Другими словами, информация о каких сущностях будет учитываться (типы объектов), чем они будут характеризоваться (атрибуты) и что во что может входить (входимость типов объектов). Например, мы будем учитывать информацию о помещениях и стульях, причем стулья могут входить в помещения и будут характеризоваться инвентарным номером, годом начала эксплуатации и сроком службы. Или другой пример: мы будем учитывать документы, причем документы будут входить в папки и будут характеризоваться наименованием, фамилией автора, датой создания и т.д. В первом случае мы должны зарегистрировать в Lotsia PDM PLUS типы объектов «помещение» и «стул», указать входимость типа объекта «стул» в тип объекта «помещение», зарегистрировать атрибуты «Инвентарный номер», «Год начала эксплуатации» и «Срок службы» и сопоставить эти атрибуты типу объекта «стул». Во втором случае мы должны зарегистрировать в Lotsia PDM PLUS типы объектов «папка» и «документ», указать входимость типа объекта «документ» в тип объекта «папка», зарегистрировать атрибуты «Наименование», «Автор» и «Дата создания» и сопоставить эти атрибуты типу объекта «документ».

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

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

Во втором примере наблюдается обратная ситуация. Тип объекта «документ» является слишком обобщенным. Во-первых, у разных документов различные учетные характеристики. Например, обозначение представляет собой идентификационную характеристику технических документов, но не офисных. Кроме того, чертеж детали может входить в состав детали, а договор — нет, дополнительное соглашение может входить в состав договора, а сборочный чертеж — нет. Однако существует множество видов ведомостей, которые характеризуются примерно одинаковым набором атрибутов. Похожая ситуация, например, со схемами. Поэтому имеет смысл рассмотреть вопрос о выделении отдельных типов объектов «ведомость», «схема», «перечень» и т.д. и назначить для них по отдельному атрибуту со своим списком значений, характеризующим вид документа. А для чертежей деталей, сборочных чертежей и спецификаций лучше выделить «персональные» типы объектов. Соответственно больше логики будет и при указании входимости типов объектов. Приведенный выше пример с типами документов характерен для машиностроительной отрасли, хотя Lotsia PDM PLUS не имеет отраслевой привязки. При желании можно легко привести (или даже читатели сами могут представить) аналогичные примеры для финансовых, проектных и любых других типов документов из других предметных областей. Более того, правда жизни состоит в том, что, несмотря на разнотипность документов, они связаны между собой. Например, документы входящей корреспонденции могут быть связаны с заданиями на проектирование, извещениями об изменении, договорами, счетами и т.д.

Подведем краткие итоги: описав модель данных в Lotsia PDM PLUS, мы получаем некий шаблон, логические ограничения которого автоматически применяются при работе пользователя в системе. В принципе, этого достаточно для того, чтобы начать работу с Lotsia PDM PLUS. Важным моментом является то, что все элементы шаблона модели данных при необходимости можно изменять, подстраиваясь под бизнес-процессы предприятия.

Далее мы пробуем создать в Lotsia PDM PLUS небольшой проект — так сказать, «деревце». Здесь всё просто. Рассмотрим данный процесс на примере первого варианта с помещениями и стульями (вопрос о степени детализации типов объектов мы затрагивать не будем, чтобы не усложнять пример). Создаем объект типа «помещение». Вводим его описание. Теперь в созданное помещение добавляем новый объект типа «стул». Вводим его описание, добавляем поочередно все или некоторые атрибуты, вводим их значения. Смотрим, что получилось. Получилось дерево из двух уровней. На первом уровне — помещение, а на втором — стул, причем конкретное помещение и конкретный стул. Или по-другому — информационные объекты, соответствующие конкретному помещению и конкретному стулу. Можно последовательно добавить несколько стульев. А теперь мы хотим просмотреть информацию о стульях. Для этого нужно выделить строчку с одним стулом, перейти на вкладку «Все атрибуты» и просмотреть таблицу с атрибутами. Здесь атрибуты отсортированы по группам, а затем по названиям атрибутов. Предположим, что все атрибуты в одной группе — тогда информация о стуле будет доступна в табличной форме в том порядке следования строк, который определяется сортировкой по названию атрибута (рис. 1).

Рис. 1. Табличное представление значений атрибутов

Рис. 1. Табличное представление значений атрибутов

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

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

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

Рис. 2. Представление значений атрибутов в атрибутивных формах

Рис. 2. Представление значений атрибутов в атрибутивных формах

И еще: для типов объектов, соответствующих документам, кроме атрибутивных форм нужно сопоставить форму «Документы архива». Как правило, через эту форму происходит обращение пользователей к файлам документов — открытие их для редактирования, просмотра или печати.

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

Еще один важный момент. Пользователи хотят видеть всю интересующую их информацию в одной форме. Например, в форме для стула — информацию о помещении, где он находится. Ответ вроде бы простой: переключитесь на помещение и посмотрите информацию о нем. Сделать это, казалось бы, не сложно, но многолетний опыт внедрения свидетельствует об обратном. Разработчики сложнейших проектов и технических систем говорят, что им как пользователям это сложно! Чем им можно помочь? Такой простой вещью, как записать в атрибуты стула информацию о помещении, то есть попросту унаследовать ее. Но как это реализовать? Получается, что пользователь, прежде чем создать новый стул в помещении, должен скопировать в буфер обмена информацию из формы помещения, а затем при создании стула вставить ее из буфера обмена в соответствующее поле в форме. А вот это уже сложнее. Если же говорить о документации проектных организаций, то здесь наследование нескольких атрибутов должно идти по ряду ветвей на несколько уровней вниз — например от договора до чертежей. Вот это уже совсем сложно. О том, с помощью какого инструмента в Lotsia PDM PLUS решается данная задача, и пойдет речь далее.

Основное, к чему стремятся пользователи, — это к упрощению работы с информацией, то есть к упрощению своей текущей работы. Говоря языком пользователей — к уменьшению числа кликов мышью. Наследование значений атрибутов и добавление новых объектов (стульев) в проект (помещение) тоже относится к упрощаемым процедурам. Упрощение состоит в том, чтобы описать и выделить последовательность обращений пользователя к тому или иному пункту меню либо к той или иной функции для достижения определенного результата в отдельную макрофункцию. Такие макрофункции в терминах Lotsia PDM PLUS называются действиями. То есть пользователь в ходе сеанса работы в Lotsia PDM PLUS выполняет действия с понятными названиями, например «Добавить стул», «Создать договор», «Выполнить отчет», «Добавить чертеж» и т.д. А действие уже содержит ряд инструкций, которые выполняются при обращении к нему. Так, при добавлении стула в обычном режиме пользователь должен выполнить примерно следующую последовательность шагов:

1. Запомнить название помещения (скопировать его в буфер обмена).

2. Создать объект типа «стул».

3. Добавить созданный объект стула в папку.

4. Добавить последовательно атрибуты стула и ввести их значения.

5. Добавить стулу атрибут с названием помещения и ввести запомненное вначале значение (вставить из буфера обмена).

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

Если же пользователь использует действие Lotsia PDM PLUS, то описанная выше последовательность шагов выполняется автоматически. Для пользователя настраивается диалоговое окно, в котором располагают поля для ввода значений атрибутов стула (рис. 3). Атрибуты помещения наследуются скрыто от пользователя. Действие Lotsia PDM PLUS привязывается к кнопке в атрибутивной форме помещения или к пункту меню. Пользователь вызывает действие, например, нажав на кнопку в форме помещения, заполняет поля в диалоговом окне и подтверждает ввод. Просто? Да! Конечно, администратору работы больше, но за это он и получает зарплату — за настройку Lotsia PDM PLUS для простой и безошибочной реализации пользователями своих задач.

Рис. 3. Диалог выполнения действия

Рис. 3. Диалог выполнения действия

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

Таким образом, информационное наполнение базы данных растет, причем в ряде случаев достаточно быстрыми темпами. На следующем этапе освоения Lotsia PDM PLUS возникает потребность в поиске и получении аналитической или сводной информации либо просто печатных форм. Очевидно, что внесение информации в базу данных бесперспективно, если под рукой нет инструментов, позволяющих ее использовать. Руководству требуется возможность получать сводные аналитические формы, например, по количеству и стоимости договоров, по количеству выпущенной документации, по занятости сотрудников, да хотя бы и по количеству стульев, а конечным пользователям — быстро находить документ, применять к нему функцию заимствования и выпускать новые документы, что будет гораздо быстрее, чем подготавливать документ с нуля. Также очень ценится исполнителями возможность быстрого оформления документа на бланке или автоматическое заполнение документа по шаблону, то есть такие мелочи, которые минимизируют в трудовом процессе самые рутинные операции.

Для подготовки аналитических форм в Lotsia PDM PLUS применяется генератор отчетов. Администратор производит настройку отчетов, а пользователи запускают их на выполнение, указывая какие-либо дополнительные параметры отбора, например период времени, за который требуется сформировать отчет. Полученный отчет можно распечатать или сохранить в MS Word либо в MS Excel. Настройка отчетов в Lotsia PDM PLUS выполняется путем указания отбираемых типов объектов, перечня включаемых в форму атрибутов, дополнительных условий отбора, критериев сортировки и группировки. Простенький отчет (перечень тех же стульев) в Lotsia PDM PLUS настраивается буквально за несколько минут. Очень важно и то, что из отчета двойным щелчком мыши по строке можно открыть информационный объект, сведения о котором отображаются в этой строке (рис. 4).

Рис. 4. Простейший отчет в Lotsia PDM PLUS

Рис. 4. Простейший отчет в Lotsia PDM PLUS

Для поиска информации можно использовать настраиваемые поисковые формы. В формы можно «зашить» любые базовые условия отбора. Чем это хорошо? Если форма предназначена для поиска стульев, то она будет искать только стулья. Пользователю достаточно будет нажать Enter, чтобы получить список всех доступных ему стульев. Но в то же время пользователь может уточнить в форме, какие именно стулья он хочет найти — например стулья, эксплуатирующиеся с 1982 года. Этот простой механизм очень эффективен для конечных пользователей. Кстати, те же отчеты также являются механизмом поиска. А почему нет? В них тоже встраиваются условия отбора, зачастую даже более сложные, чем в поисковых формах, а пользователь, добавляя свои условия, сокращает объем выводимой информации для более целенаправленного ее изучения.

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

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

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

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

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

Для начала правильным решением было бы не закрывать для пользователей возможность обмена свободными сообщениями. Во-первых, идет привыкание; во-вторых, осуществляется обмен ссылками на объекты и на документы архива, а не физическая пересылка файлов внутри сети (хотя такое тоже возможно); в-третьих, в Lotsia PDM PLUS очень удобно реализована функция просмотра истории переписки: сообщения выстраиваются в иерархическую структуру — от самого раннего до самого позднего (рис. 5); в-четвертых, можно посмотреть отчет о доставке сообщения: кто и когда его прочитал, а кто — нет; в-пятых, пользователям будет проще общаться с системным администратором внутри системы, а не по телефону или через внешнюю почту.

Рис. 5. История переписки в Lotsia PDM PLUS

Рис. 5. История переписки в Lotsia PDM PLUS

Затем можно начинать настройку маршрутов прохождения документов. Для начала желательно настроить какой-нибудь несложный маршрут. Пока он проходит обкатку, выясняются требуемые доработки, которые можно сразу же реализовать. Сначала лучше описать маршруты «как есть» — не надо сразу же бросаться оптимизировать процессы: пользователи этого не поймут и не примут новый порядок работы, а в результате работа в системе будет саботироваться. Здесь преимущество Lotsia PDM PLUS проявляется в том, что она позволяет автоматизировать процессы «как есть», не заставляя пользователей менять привычную последовательность выполнения работ. Lotsia PDM PLUS как бы подстраивается под пользователей, смягчая перевод процессов на электронные рельсы.

Спустя какое-то время, когда работа в Lotsia PDM PLUS станет привычной и естественной, всплывут проблемные места, раньше не бросавшиеся в глаза. На поверхность выйдут не совсем логичные последовательности, лишние этапы маршрутов и операции пользователей. Таким образом, Lotsia PDM PLUS позволит начать процесс оптимизации процессов и их переориентацию на электронный документооборот.

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

САПР и графика 11`2007

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

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

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

ИНН 7751031421 ОГРН 5167746333838

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

ИНН 7726601967 ОГРН 1087746953557

Рекламодатель: ООО «НТЦ ГеММа»

ИНН 5040141790 ОГРН 1165040053584