3 - 2021

О настройке Lotsia PDM PLUS

Дмитрий Садовников

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

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

Итак, существует некоторая простая реализация системы управления технической документацией для проектной организации. Есть дерево проекта с исходными данными, перечнем работ, объектами проектирования с проектной и рабочей документацией (рис. 1).

Рис. 1. Существующее дерево проекта

Рис. 1. Существующее дерево проекта

Чтобы отслеживать ход выполнения работ (папка Работы и задания), реализуем автоматизированное создание заданий. Для этого зарегистрируем тип объекта Задание (рис. 2).

Рис. 2. Регистрация типа объекта Задание

Рис. 2. Регистрация типа объекта Задание

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

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

Рис. 3. Атрибуты типа объекта Задание

Рис. 3. Атрибуты типа объекта Задание

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

Кроме того, необходимо установить разрешенную входимость: задания могут входить в состав работ и папок заданий (рис. 4).

Рис. 4. Входимость типа объекта Задание

Рис. 4. Входимость типа объекта Задание

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

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

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

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

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

В данной реализации системы принята разметка формы с расположенными слева кнопками с надписями (рис. 5).

Рис. 5. Шаблон формы

Рис. 5. Шаблон формы

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

Рис. 6. Вариант шаблона формы

Рис. 6. Вариант шаблона формы

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

Итак, создадим из шаблона форму и добавим в нее несколько атрибутов задания: шифр проекта, выдающее подразделение, принимающее подразделение, даты выдачи (плановая и фактическая), содержание, примечание, а также служебный атрибут «ID ГИПа». Lotsia PDM PLUS добавит поля атрибутов в свободное место под уже занятой областью (рис. 7).

Рис. 7. Добавление в форму атрибутов

Рис. 7. Добавление в форму атрибутов

Расположим поля так, как нужно, и отредактируем текстовые метки (рис. 8).

Рис. 8. Настроенная форма задания

Рис. 8. Настроенная форма задания

К заданию обычно прилагаются документы, например исходные данные, и пользователю удобнее их видеть прямо из карточки задания. Документы исходных данных являются отдельными объектами, а кроме того, один и тот же документ может прилагаться к нескольким заданиям. Прилагаемые документы не записываются в атрибут, хотя так тоже можно сделать, а связываются с заданием отдельными информационными связями. Для отображения списка связанных объектов в Lotsia PDM PLUS предусмотрен отдельный вид форм. Они выглядят как таблицы, поскольку содержат списки, и тоже могут настраиваться в части состава столбцов и оформления. Форма со связанными объектами встраивается в форму задания. То есть какая­то часть карточки задания будет содержать таблицу с прилагаемыми документами. Встроенных таблиц с информацией по разным связям может быть несколько. Сейчас демонстрировать простейшую операцию вставки формы в форму мы не будем, а позже покажем результат.

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

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

Во­первых, для заданий на практике таких областей не больше трех: само задание, исходные данные, отчеты исполнителей.

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

Готовую форму нужно привязать к типу объекта Задание. В Lotsia PDM PLUS есть профили пользователей, содержащие множество настроек рабочего пространства, специфичных для конкретного пользователя или группы пользователей. Одной из таких настроек является сопоставление типам объектов форм — ее мы и выполним. Одна и та же форма может быть привязана к разным типам объектов. Например, для разных типов документов используются объекты­папки и форму для них можно настроить одну, но с разными кнопками или областями, отображающимися по условию. Это очень удобная возможность, которая значительно уменьшает количество форм и трудоемкость настройки. Применительно к заданиям форма уникальная и должна быть привязана к одному типу объекта. Выполнение привязки является предельно простой процедурой и в данной публикации не демонстрируется.

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

В Lotsia PDM PLUS есть инструмент, называемый Действия, который дает возможность заменить базовые команды макрокомандами. Базовые команды мы уберем из интерфейса пользователя через упомянутую выше настройку профиля. Существует еще один более мощный и интересный инструмент, который включает и действия, но, напомним, — мы пока идем по простому пути.

Итак, нам требуется настроить действие, работающее по следующему алгоритму:

  1. Проверить текущий объект. Если это задание, то установить режим редактирования. В противном случае — режим создания.
  2. Если режим редактирования, считать редактируемые атрибуты задания, чтобы показать в форме ввода. Иначе — считать атрибуты, наследуемые от работы и не подлежащие редактированию в данном действии (идентификатор ГИПа, идентификатор проекта, шифр проекта и подобные).
  3. Показать форму ввода.
  4. Если режим создания, создать в составе работы задание. Иначе перейти к шагу установки атрибутов.
  5. Установить атрибуты, введенные в форме.

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

Рис. 9. Переменная действия

Рис. 9. Переменная действия

Недостающие переменные можно создать по мере написания функций.

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

Рис. 10. Вставка функции в действие

Рис. 10. Вставка функции в действие

Шаги 1 и 2 реализуем, как показано на рис. 11.

Рис. 11. Начальные шаги действия

Рис. 11. Начальные шаги действия

Небольшие комментарии по тексту функций: на шаге  1, согласно алгоритму, получаем тип текущего объекта (строка 1) и устанавливаем режим (строка 2). В строке 3 проверяем режим и либо продолжаем данный шаг и получаем наследуемые атрибуты работы и подразделение текущего пользователя, либо переходим на шаг получения атрибутов задания. Затем переходим на шаг заполнения формы.

Настройка формы ввода сильно облегчается за счет возможности копирования через буфер обмена. Скопируем атрибутивную форму и после вставки сопоставим переменные атрибутам. Форма будет точно такая же, как атрибутивная (рис. 12).

Рис. 12. Скопированная форма ввода

Рис. 12. Скопированная форма ввода

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

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

Рис. 13. Шаги с функционалом создания задания 
и установки атрибутов

Рис. 13. Шаги с функционалом создания задания и установки атрибутов

На этом действие можно считать готовым. В атрибутивной форме работы добавим кнопку создания задания, а в форме задания — кнопку редактирования (рис. 14).

Рис. 14. Атрибутивные формы работы и задания 
с новыми кнопками

Рис. 14. Атрибутивные формы работы и задания с новыми кнопками

Теперь, нажав в форме объекта работы кнопку создания задания, получим возможность ввести данные и создать задание (рис. 15).

Рис. 15. Созданное задание

Рис. 15. Созданное задание

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

Рис. 16. Развитие атрибутивной формы задания

Рис. 16. Развитие атрибутивной формы задания

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

По заданиям теперь можно строить отчеты и получать нужную аналитику. Встроенный генератор отчетов Lotsia PDM PLUS позволит с легкостью настроить нужные отчеты.

Теперь настроим несложный процесс выдачи задания. В Lotsia PDM PLUS встроенный редактор шаблонов работ (бизнес­процессов) Workflow позволяет составить схему прохождения для процесса, указать условия переходов между задачами, настроить рабочие формы, привязать действия для выбора и назначения исполнителей, прозрачной установки атрибутов и прав доступа. Кстати, статусы тоже являются атрибутами, поэтому можно использовать любые понятные значения.

Открыв редактор шаблонов работ, составим такой маршрут процесса выдачи задания (рис. 17).

Рис. 17. Маршрут процесса выдачи задания

Рис. 17. Маршрут процесса выдачи задания

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

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

Рис. 18. Пример формы задачи принятия задания

Рис. 18. Пример формы задачи принятия задания

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

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

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

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

Рис. 19. Действия на задаче

Рис. 19. Действия на задаче

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

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

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

Рис. 20. Действия на переходе принятия задания

Рис. 20. Действия на переходе принятия задания

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

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

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

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

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

На рис. 16 была показана атрибутивная форма задания с кнопкой Выдать. К ней мы привязали действие, запускающее процесс выдачи. В форме стартовой задачи можно проверить и скорректировать данные перед отправкой (рис. 21).

Рис. 21. Стартовая задача процесса выдачи задания

Рис. 21. Стартовая задача процесса выдачи задания

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

Нажав в карточке задания кнопку Контроль процессов, можно просмотреть отчет по прохождению задания со статусами задач (рис. 22).

Рис. 22. Действия на переходе принятия задания

Рис. 22. Действия на переходе принятия задания

На этом завершим нашу публикацию о настройке Lotsia PDM PLUS.

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

Еще больше примеров возможностей системы Lotsia PDM PLUS, а также практики ее внедрения и применения доступно на сайтах lotsia.com и plm­conference.com. Если тематика статьи вас заинтересовала, для получения дополнительной информации вы можете связаться с компанией «Лоция Софт», используя контактные данные, указанные на сайте lotsia.com

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