Цифровые технологии всё интенсивнее проникают в деятельность организаций. Способность организации внедрять и использовать цифровые технологии определяет её конкурентоспособность [1]. К проектам стали предъявляться более жесткие ограничения по времени, из-за чего появились гибкие методологии для их управления [2]. Качество принимаемых руководителем решений во многом стало определять успешность проекта. Системы поддержки принятия решений (СППР) призваны повысить эффективность работы руководителей.
Проект по разработке спутника может осуществляться годами с привлечением сотни высококвалифицированных специалистов, а проект по разработке веб-приложения может выполняться силами пары человек. Для настолько разных проектов используются разные способы принятия решений. Способ принятия решений зависит от методологии. Выделяют три группы методологий управления проектом: классические (Waterfall), корпоративные (Enterprise) и гибкие (Agile) [3, 4].
Классическим методологиям свойственно последовательное выполнение проекта. При использовании данной методологии, как правило, выделяют этапы: инициализация, планирование, выполнение, верификация, внедрение, завершение. Здесь большое внимание уделяется стратегическому планированию. Обнаружение ошибок негативно сказывается на проекте из-за необходимости возврата к предыдущим этапам [2].
Для Enterprise методологий свойственно разбиение проекта на итерации, которые, в свою очередь, поделены на этапы (рис. 1). Результатом выполнения каждого этапа является документация (артефакт). В рамках одной итерации все этапы выполняются последовательно, а входными данными для каждого этапа служат результаты предыдущих.
Рис. 1. Enterprise-схема управления проектом
Рис. 2. Agile-схема управления проектом
Для гибких методологий свойственно разделение проекта на спринты – маленькие итерации продолжительностью 1–4 недели (рис. 2). У каждого спринта определены свои задачи, приоритеты и сроки выполнения. В рамках каждого спринта с учётом промежуточных результатов могут приниматься корректировочные решения, призванные оптимизировать проектную ситуацию. По результатам предыдущего спринта планируется следующий и т.д.
В классических и Enterprise-методологиях большее внимание уделяется стратегическим решениям, а в гибких – оперативным. В отличие от других групп методологий, в гибких проектная группа невелика и насчитывает 5–20 человек, а вес каждого участника значительно выше. В зависимости от выбранной методологии, для принятия решений используются различные метрики, а от руководителя проекта требуется иная комбинация компетенций [4].
Цель исследования – выработка подхода по построению и эксплуатации систем поддержки принятия решений (СППР) для повышения эффективности деятельности руководителя проекта.
Материалы и методы исследования
При выработке решений по проекту возникает проблема, заключающаяся в субъективности этого процесса. Для повышения эффективности (под эффективностью здесь понимается отношение степени успешности проекта к понадобившимся временным и материальным затратам на его выполнение) принимаемых решений используют различные подходы, как субъективные (например, голосование), так и точные, с привлечением программных средств, в частности СППР [5].
В контексте рассматриваемой предметной области (управление проектом) СППР должна оказывать помощь руководителю посредством решения перечня задач вида:
– формирование рекомендаций по подбору команды и выбору методологии;
– расстановка приоритетов для задач;
– детектирование проблем и аномалий;
– выработка рекомендаций по улучшению показателей проекта.
В СППР выделяют две группы компонентов: ядро и сервисные модули. Без компонентов ядра СППР не способна функционировать. Сервисные модули используются для повышения эффективности эксплуатации СППР [6].
Ядро системы включает:
– механизм логического вывода (МЛВ);
– базу знаний (БЗ);
– интерфейс пользователя (ИП).
Перечень сервисных модулей включает:
– подсистему обработки и накопления знаний (ПОНЗ);
– программный интерфейс (ПИ);
– подсистему диагностики и объяснения (ПДО).
МЛВ используется для выдачи рекомендаций для пользователя (руководителя), которые формируются на основе накопленных знаний (подробнее об этом далее в статье). Мощность СППР определяется в первую очередь качеством БЗ, которое выражается в количестве, полноте, достоверности и актуальности накопленных в ней знаний [7]. ПОНЗ позволяет пополнять СППР новыми знаниями. Без этого система не только не сможет модернизироваться, но и даже будет постепенно деградировать из-за свойства знаний утрачивать свою актуальность со временем [8].
ПДО служит для диагностики и объяснения результатов. Диагностика необходима для детектирования ошибок. Под объяснением подразумевается описание для пользователя процессов и первопричин, которые привели к выдаче той или иной рекомендации СППР. При использовании СППР необходимо преобразовывать данные, полученные в процессе управления проектом, в знания. Как уже говорилось ранее, в СППР должны быть предусмотрены свои интерфейсы, отвечающие за взаимодействие с пользователями и программами (рис. 3).
Рис. 3. Схема обмена информацией между СППР и внешним миром
Для преобразования информации в знания, исходя из специфики данных, применяются специально разработанные алгоритмы, из-за чего необходимо под каждую предметную область принятия решений разрабатывать отдельную систему.
Преобразование информации в знания есть процесс интеллектуальной обработки данных. Получаемые в ходе обработки знания формируют БЗ. Интеллектуальная обработка данных должна не только производиться посредством заранее заложенных в СППР алгоритмов, но и использовать для этого уже накопленные знания [9].
Можно выделить два типа знаний по времени их появления:
– знания, заложенные в систему до начала проекта;
– знания, формирующиеся по мере осуществления проекта.
В качестве знаний, изначально заложенных в систему, могут выступать:
– существующие методологии и рекомендации для них;
– сведения о персонале организации (компетенции, стаж, soft skills и т.д.);
– сведения о ранее законченных проектах.
В качестве знаний, формирующихся по мере выполнения проекта, могут выступать:
– перечень задач, степени важности и приоритеты их выполнения;
– объем планируемой и выполненной работы, оценка утилизации ресурсов;
– показатели и характеристики сотрудников, получаемые в ходе оценки персонала.
Пополнение БЗ является сложным процессом, особенно когда знания представлены в нечетком или неполном виде. Существует множество методов, позволяющих автоматизировать процесс формирования БЗ, однако адекватность использования каждого из них находится в сильной зависимости от предметной области [10].
Результаты исследования и их обсуждение
Системы поддержки принятия решений относятся к интеллектуальным системам. Интеллектуальные системы – это системы с целью [11]. Цель в СППР может быть представлена целевой функцией (ЦФ), обозначающей вероятность успешного завершения проекта или его итерации в заранее определенный срок.
В общем случае выполнение всех задач в проекте может не являться обязательным требованием для его успешного завершения. Чаще всего подобное встречается в проектах, где используется гибкая методология. При данных условиях задачи делятся на градации важности: «критическая», «основная», «второстепенная» и т.п. Этот момент также должен учитываться при построении целевой функции в СППР.
Для выполнения задачи в проекте необходимо сначала выполнить её подзадачи. Задачи формируют иерархическую структуру, где выполнению задач верхних уровней предшествует выполнение задач нижних уровней. Для примера на рис. 4 критические задачи обозначены толстой обводкой, основные – тонкой, второстепенные – пунктирной.
Рис. 4. Иерархическая структура задач проекта
Количество задач и уровней иерархии может увеличиваться в процессе проектной деятельности. Это обусловлено тем, что не всегда возможно предугадать и спланировать весь набор задач, которые необходимо выполнить для успешного выполнения проекта.
Схема вычисления значений ЦФ сильно зависит от предметной области и используемых методов реализации МЛВ. Примером одного из способов вычисления значений ЦФ выступает выражение, которое является модификацией функции логистической регрессии:
где Z – вероятность успешного выполнения задачи;
z1, z2, …, zn – вероятности успешного выполнения подзадач;
f1, f2, …, fm – факторы, влияющие на вероятность успешного выполнения задачи Z;
ω1, ω2, …, ωm – веса факторов.
Факторами могут быть объем работ, планируемое время выполнения, потраченное время, опыт сотрудников (работающих над задачей), процент выполнения и т.д.
Тогда, исходя из данного примера, СППР должна таким образом подбирать веса факторов, чтобы итоговая ЦФ достаточно точно предсказывала вероятность успешного выполнения проекта. Подбор весов должен осуществляться на основе знаний, накопленных системой. После построения ЦФ система может начать выполнять свою основную консультационную функцию по распределению заданий между членами команды. В целом задача по распределению заданий между сотрудникам во многом похожа на задачу распределения нагрузки в распределенной вычислительной системе [12].
Иначе говоря, конечная цель СППР – это максимизация ЦФ, которая достигается в процессе выполнения ранее обозначенных задач: формирование компетентной команды, выбор оптимальной методологии, детектирование проблем, выработка рекомендаций.
СППР исполняет рекомендательно-консультационную функцию. Система помогает акцентировать внимание на проблемных моментах, выдает рекомендации по их решению. Тем не менее в конечном итоге решения должны приниматься руководителем, исходя из личного опыта и профессионализма, а СППР оказывает в этом помощь.
Проектная группа состоит из руководителя и команды. Руководитель проекта взаимодействует с СППР непосредственно, внося в систему информацию и получая от неё рекомендации через интерфейс пользователя. Взаимодействие членов команды с СППР разумно организовать опосредованно, через программные средства, обеспечивающие автоматический сбор данных по проекту. Примером таких систем являются Jira, ClickUp, Wrike, Pivotal Tracker.
Взаимодействие проектной группы (руководителя и иных участников проекта) с системой и направления распространения потоков данных в СППР представлены на рис. 5.
Рис. 5. Взаимодействие проектной группы с СППР
Из рис. 5 видно, что взаимодействие участников проекта с СППР является опосредованным и однонаправленным. С точки зрения системы участники, выполняющие задачи по проекту, являются лишь источниками информации (метрик). Основные результаты работы СППР должны быть доступны только руководителю проекта, так как излишняя осведомленность участников может в отдельных случаях негативно сказываться на достоверности получаемых СППР данных.
Заключение
СППР могут значительно облегчить процесс управления проектом. Для эффективной работы СППР необходим сбор как можно более достоверной и точной информации, с помощью которой система сможет осуществлять свои консультационные функции. Построение и внедрение СППР являются нетривиальными задачами, которые требуют значительных интеллектуальных и временных инвестиций. Однако в перспективе они хорошо окупаются.
Библиографическая ссылка
Шульман В.Д., Шкирмонтова Е.А., Ерёмин О.Ю. ПОСТРОЕНИЕ И ЭКСПЛУАТАЦИЯ СИСТЕМ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ В ПРОЕКТНОЙ ДЕЯТЕЛЬНОСТИ // Современные наукоемкие технологии. – 2021. – № 11-2. – С. 313-318;URL: https://top-technologies.ru/ru/article/view?id=38930 (дата обращения: 21.11.2024).