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

ИНН 7726601967 ОГРН 1087746953557

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

ИНН 7807258360 ОГРН 1227800102375

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

ИНН 7715938849 ОГРН 1127747049209

7 - 2023

Технология управления задачами в Appius-PLM

Никита Багрянцев, ведущий специалист отдела внедрения, компания «АППИУС»
Никита Багрянцев, ведущий специалист отдела внедрения, компания «АППИУС»

Современные программные комплексы PDM/PLM-класса предлагают множество инструментов для работы специалистов по различным направлениям: это и организация электронного архива конструкторских разработок, и технологическая подготовка производства, и трансформация данных для учетной системы. Согласно аббревиатуре, PLM — это управление жизненным циклом изделия (УЖЦИ), и в рамках данной статьи мы подробнее остановимся на инструментах управления, а именно — на работе с задачами, поручениями и сопутствующими интерфейсами в системе Appius-PLM.

Общее назначение подсистемы задач

Чем же является задача в системе Appius­PLM и для достижения каких целей она применяется?

С точки зрения системного администратора, так же как и в других конфигурациях на платформе 1С:Предприятие, это определенный объект данных, на который может быть завязана часть функционала, относящаяся к организации работы в базе данных. Если же рассматривать задачу от лица рядового пользователя, то задача — это в первую очередь инструмент, который помогает проводить коллективное взаимодействие между сотрудниками по различным направлениям. Сюда же можно отнести и работу с проектами, процесс согласования, проведение извещения и пр. Львиная доля этих процессов использует функционал подсистемы задач на каждом из этапов.

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

Рис. 1. Схема применения задач для различных пользователей

Рис. 1. Схема применения задач для различных пользователей

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

Рис. 2. Интерфейс панели задач

Рис. 2. Интерфейс панели задач

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

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

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

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

Рис. 3. Указание плановой даты завершения задачи при создании и фактической во время ее выполнения

Рис. 3. Указание плановой даты завершения задачи при создании и фактической во время ее выполнения

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

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

Рис. 4. Список контролирующих лиц

Рис. 4. Список контролирующих лиц

Для отслеживания этапов выполнения задач предусмотрено несколько статусов, список которых может различаться в зависимости от роли участия пользователя (рис. 5). Так, инициатор имеет возможность закрытия задачи с одним из двух статусов (выполнена или отклонена), а также за исполнителя менять этап работы с поручением (в процессе, на паузе, отложена и пр.). Ответственный за выполнение не имеет возможности самостоятельно закрыть задачу, он может только установить пометку «Готова к сдаче» для передачи результатов работы на проверку. Кроме случая постановки задачи самому себе — и такое в системе возможно.

Рис. 5. Статусы выполнения задачи

Рис. 5. Статусы выполнения задачи

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

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

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

Задача как основной инструмент функционирования бизнес­процессов и проектов

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

Рис. 6. Область применения задач в различных подсистемах

Рис. 6. Область применения задач в различных подсистемах

К ним можно отнести бизнес­процесс согласования, подсистему «Управления проектами», а также работу с извещениями об изменении. По каждому из этих направлений задача выступает основным объектом, обеспечивающим достижение поставленных целей.

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

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

Рис. 7. Вид запущенного бизнес-процесса согласования. Каждый согласуемый элемент имеет связь с соответствующей задачей

Рис. 7. Вид запущенного бизнес-процесса согласования. Каждый согласуемый элемент имеет связь с соответствующей задачей

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

Рис. 8. Задача проведения извещения

Рис. 8. Задача проведения извещения

Особую роль задачи играют в рамках подсистемы «Управления проектами», предназначенной для разработки календарных планов, распределения ресурсов по этапам, отслеживания состояния процесса выполнения и анализа объемов работ в рамках конструкторско­технологической подготовки производства. Более подробно об организации проектного подхода на предприятии можно ознакомиться, используя «Управление проектами» («Управление проектами в системе Appius­PLM — инструмент оперативного контроля КТПП при работе “под Заказ” на машиностроительном предприятии “Винета”». — «САПР и графика». 2023. № 4).

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

Рис. 9. Пример вида проекта: структурное дерево этапов, окно настроек выбранного элемента

Рис. 9. Пример вида проекта: структурное дерево этапов, окно настроек выбранного элемента

Инструменты контроля загруженности пользователей

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

Каждый из таких отчетов, как: «Мониторинг загрузки трудовых ресурсов (тепловая карта)», «Мониторинг выполнения задач» и «График вовлечения сотрудников», позволяет получить определенный срез данных о работе сотрудников с различных точек зрения. При необходимости их можно вывести сразу на печать или сохранить в табличном виде на локальном компьютере.

Отчет «Мониторинг выполнения задач» позволяет вывести данные обо всех поручениях, которые, например, были отправлены определенному исполнителю или группе исполнителей. Дополнительно для вывода доступны варианты отчета с привязкой к каким­либо элементам, а кроме того, у пользователя есть возможность отображения данных по всем задачам, которые доступны ему для выполнения. Наряду с этим, можно указать, какие именно поля в задачах будут представлены в отчете, — за это отвечает набор соответствующих настроек (рис. 10).

Рис. 10. Пример формирования отчета «Мониторинг выполнения задач»

Рис. 10. Пример формирования отчета «Мониторинг выполнения задач»

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

Рис. 11. Пример вывода отчета «График вовлечения сотрудников»

Рис. 11. Пример вывода отчета «График вовлечения сотрудников»

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

Рис. 12. Пример отчета «Мониторинг загрузки трудовых ресурсов»

Рис. 12. Пример отчета «Мониторинг загрузки трудовых ресурсов»

В заключение

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

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

Более подробную информацию всегда можно найти на нашем сайте www.appius.ru. Следите за нами в соцсетях.

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

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

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

ИНН 7751031421 ОГРН 5167746333838

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

ИНН 7726601967 ОГРН 1087746953557

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

ИНН 5040141790 ОГРН 1165040053584