В настоящее время многие инновационно-активные промышленные предприятия при управлении сложными проектами широко используют набор программных средств, которые обеспечивают процесс принятия решений в области планирования, контроля, учета и анализа, координации результативности различных этапов указанных проектов. В связи с этим формируется устойчивый спрос на программные разработки, реализующие функции интегрированных систем поддержки принятия решений (СППР) по проектному управлению инновациями. Указанные разработки должны решать задачу информационного обеспечения лиц, принимающих решения (ЛПР), всем спектром данных с учетом разнородности используемых различными подразделениями предприятия характеристик проекта, а также программных средств. Последнее обстоятельство вызывает затруднения в координации информационных потоков и, как следствие, недостаток релевантной и полной информации у ЛПР различного уровня. Одним из способов обеспечения взаимосвязи управленческой информации в единое целое в рамках конкретного предприятия является применение инструментов контроллинга [1], ориентированных, в первую очередь, на комплексный анализ данных из различных функциональных областей для выработки управленческих решений [2, 3].

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

– адаптация организационной структуры контроллинга проектов к изменяющимся факторам внутренней и внешней среды (источникам изменения проекта) с учетом различных вариантов позиционирования контроллеров в структуре предприятия в целом;

– обоснование изменения набора инструментов управления проектами в зависимости от мониторинга результатов выполнения его этапов;

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

Данные особенности определяют развитие функционала СППР, решающей задачи контроллинга в направлении реализации функций экспертной системы, основанной на знаниях и реализующей алгоритмы обработки информации для построения комплексной логико-временной модели проекта. В свою очередь, указанная модель инновационного проекта должна на основе прогностических оценок последствий принимаемых решений, а также динамической системы ключевых показателей результативности определять необходимые изменения в наборе мероприятий по минимизации негативного влияния внутренних и внешних факторов. Очевидно, что в условиях нестабильности среды модель проекта должна иметь возможность адаптации своей структуры и основных параметров с учетом взаимосвязи этапов проекта с источниками изменений [5–8]. На рисунке 1 показана логико-временная модель инновационного проекта.

В рамках данной модели источники изменений Q_i, оказывающие влияние на показатели результативности этапов проекта X_i, имеют многоуровневую структуру, которая  характеризуется следующими особенностями:

– отсутствие логико-временных связей между отдельными источниками изменений (взаимосвязь существует только между уровнями);

– источники изменений предшествующего уровня являются предпосылками источников изменения, находящихся на следующих уровнях. Источники изменения уровня (i – 1) могут быть предпосылками только источников изменения уровня i;

– внешние источники изменения не имеют предпосылок и являются предпосылками внутренних источников изменения следующего уровня.

Важной задачей при управлении проектами на промышленном предприятии с использованием экспертной СППР является учет влияния, оказываемого различными источниками изменения (факторами неопределенности) [9], на основе различных алгоритмов прогнозирования [10]. Эти алгоритмы направлены на определение вероятности появления различных источников изменения и расчет по каждому из них степени влияния, оказываемого на характеристики проекта.

На рисунке 2 приведена блок-схема алгоритма, реализующего разработанные авторами данной статьи объектно-ориентированные подходы [6] и позволяющего корректировать длительности проекта в зависимости от степени влияния различных источников изменения Q_i.

На рисунке 3 приведена блок-схема алгоритма, реализующего разработанные авторами данной статьи процедуры [8, 9] и позволяющего учитывать влияние источников изменения на затраты, связанные с выполнением работ проекта. В данном случае в результате анализа внутренней и внешней среды деятельности промышленного предприятия на вход поступает информация о различных источниках изменения, влияющих на проект. Данная информация в формализованном виде описывается с помощью множества Q:

Q = <{E}, {T}, {I}, {D}>,

где подмножества {E} – экономические источники изменения, {T} – технологические источники изменения, {I} – международные источники изменения, {D} – внутренние источники изменения.

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

где – g-е мероприятие для i-й работы проекта, предупреждающее и ликвидирующее последствие влияния k-го экономического источника изменения; – g-е мероприятие для i-й работы проекта, предупреждающее и ликвидирующее последствие влияния k-го технологического источника изменения; – g-е мероприятие для i-й работы проекта, предупреждающее и ликвидирующее последствие влияния k-го международного источника изменения; – g-е мероприятие для i-й работы проекта, предупреждающее и ликвидирующее последствия влияния k-го внутреннего источника изменения.

С целью предупреждения непредвиденных обстоятельств и снижения степени неопределенности, помимо определения планового времени выполнения каждой из работ проекта, также рассматриваются и другие возможные сценарии его реализации, где при разных значениях показателей результативности X_i определяются соответствующие временные характеристики. В результате такого подхода вместо планового момента времени T_pl завершения работы проекта определяется некоторый временной интервал ∆T_i, который, исходя из самых оптимистических и самых пессимистических предположений, имеет минимальную (T_min) и максимальную (T_max) границы относительного планового времени выполнения (T_pl).

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

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

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

Другой алгоритм, направленный на определение затрат, связанных с обеспечением работы проекта необходимыми ресурсами с учетом влияния источников изменения, и реализующий разработанные авторами данной статьи процедуры [8, 9], представлен на рисунке 3. В общем виде данный алгоритм включает следующие четыре этапа.

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

где R_i – множество ресурсов i-й работы (i = 1, ..., n), r_ik – ресурс k-го типа (k – 1, …, K), используемый на i-й работе проекта.

2. Учет степени влияния источников изменения на проект.

Проводится анализ источников изменения из множества Q_an , по каждому из которых оценивается степень влияния на конкретный тип выделенных ресурсов, необходимых для реализации i-й работы. Формируется множество ресурсов, подверженных влиянию факторов из Q _an:

где верхний индекс * указывает на то, что ресурс находится в сильной зависимости от внешних и внутренних факторов.

Для каждого элемента из множества R^* оценивается, какие источники изменения оказывают на него воздействие. В дальнейшем рассчитываются затраты, связанные с обеспечением i-й работы каждым отдельным типом ресурсов из множества R^*. Полученные затраты суммируются:

где – j-й (j = 1, …, J) вид затрат для i-й работы ИП, связанных с k-м типом ресурсов, которые зависят от изменения внешних и внутренних факторов; V_Qan – степень влияния факторов из множества Q_an на k-й тип ресурсов.

3. Учет затрат, связанных с обеспечением i-й работы каждым отдельным типом ресурсов, не подверженных влиянию источников изменения. В данном случае создается множество, в котором для каждого элемента определяются затраты:

где верхний штрих указывает на то, что ресурс не зависит от внешних и внутренних факторов.

После этого формируется множество затрат:

,

где – j-й (j=1, …, J) вид затрат для i -й работы, связанных с k-м типом ресурсов, которые не зависят от источников изменения проекта.

Определяется суммарная стоимость затрат, связанных с обеспечением i-й работы каждым отдельным типом ресурсов, не подверженных влиянию источников изменения:

4. Оцениваются суммарные затраты, связанные с обеспечением i-й работы всем необходимым объемом ресурсов:

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

В зависимости от типа сформированной на предприятии организационной структуры проект-контроллинга можно предложить два вида архитектур экспертной СППР по управлению инновационными проектами: централизованную архитектуру сквозного контроллинга бизнес-процессов (рис. 4) и архитектуру локальной обработки информации (рис. 5).

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

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

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

Как видно из рисунка 6, информационные системы промышленного предприятия можно представить с помощью трех типов систем:

– системы класса ERP, обеспечивающие автоматизацию управления промышленным предприятием в целом;

– системы, основанные на технологии Product Lifecycle Management (PLM) и ориентированные на управление жизненным циклом продукции;

– разрабатываемая экспертная система поддержки принятия решений по управлению проектами и их изменениями.

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

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

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

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

В качестве среды для проектирования и создания БД экспертной системы поддержки принятия решений по управлению проектами и его изменениями была использована бета-версия СУБД Oracle Database 11g Express Editional, которая базируется на технологииOracle Database 11g Release 2. Код программы реализован на языке Java 8, который является объектно-ориентированным языком программирования. Подключение БД Oracle из Java осуществляется с помощью JPA. Существует достаточно большое количество реализаций данной спецификации, среди которых есть и свободные с открытым кодом. Примером такой реализации является Hibernate JPA, который был выбран для связи Java с БД Oracle. С помощью данной библиотеки осуществляется отображение объектов в структуры реляционных БД. Использование Hibernate JPA существенно сокращает время проектирования приложений, ориентированных на работу с БД, позволяя легко организовывать связь между классами Java и таблицами БД и типами данных Java и SQL. Кроме этого, Hibernate обладает средствами автоматического создания запросов и извлечения данных [12].

Интеграция экспертной СППР по управлению проектами и уже используемых на предприятии программных продуктов осуществляется с помощью подхода на основе сервис-ориентированной архитектуры (SOA), который полностью поддерживается Oracle Fusion Middleware и осуществляется посредством enterprise service bus (ESB). В данном случае создаются сервисные интерфейсы для уже реализованных или новых функций и взаимодействие приложений происходит с помощью application business connector (ABC) services. Сервисы слабо связаны между собой и вызываются путем использования коммуникационных протоколов. Основным компонентом ESB является ESB-сервер, где происходит регистрация спроектированных сервисов. Oracle enterprise service bus поддерживает работу по многим протоколам, например, таким как HTTP, FTP, SOAP, JMS, JDBC и т.д., а также обеспечивает наличие возможности сохранения передаваемых очередей сообщений либо в оперативной памяти, либо в файловой системе, либо в БД. Таким образом, посредством ESB формируется гибкая высокопроизводительная мультипротокольная коммуникационная среда для приложений, которая объединяет сервисы, создаваемые на базе стандарта Web Service Definition Language (WSDL) [13, 14].

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

Исследование выполнено при финансовой поддержке РФФИ в рамках научного проекта № 15-07-02935 А.

Литература

1. Карминский А.М., Фалько С.Г., Жевага А.А., Иванова Н.Ю. Контроллинг. М.: Форум, 2013. 336 с.

2. Шаталова О.М. Контроллинг инноваций в управлении портфелем проектов на промышленном предприятии // Современные вызовы контроллингу и требования к контроллерам: сб. науч. тр. VI Междунар. конгресса по контроллингу. 2015. С. 270–279.

3. Елфимова И.Ф. Контроллинг инноваций в системе управления предприятием // Экономинфо. 2016. № 25. С. 68–72.

4. Аристархова М.К., Зуева О.К., Зуева М.С. Технологии управления промышленным предприятием инструментами контроллинга. Уфа: Изд-во УГАТУ, 2012. 176 с.

5. Дли М.И., Стоянова О.В. Способы представления экспертных данных в системах поддержки принятия решений по управлению сложными проектами // Нейрокомпьютеры: разработка, применение. 2016. № 7. С. 21–28.

6. Stoyanova O.V. Adaptive predication of complex projects dynamics // Междунар. науч. форум: сб. тр. AMO-SPITSE- NESEFF. Смоленск, 2016. С. 97–98 (англ.).

7. Стоянова О.В. Особенности баз знаний специализированных систем компьютерного перевода в сфере технологий управления проектами // XV Национальн. конф. КИИ-2016. Смоленск: Универсум, 2016. Т. 2. С. 139–146.

8. Dli M., Ofitserov A., Stoyanova O., Fedulov A. Сomplex Model for Project Dynamics Prediction. Intern. Jour. Applied Engineering Research, 2016, pp. 11046–11049.

9. Стоянова О.В., Дли М.И. Информационно-аналитическая система управления производственными проектами машиностроения в условиях неопределенности // Программные продукты и системы. 2015. № 3. С. 49–56.

10. Стоянова О.В., Дли М.И., Белозерский А.Ю. Модели представления данных сложных производственных проектов в автоматизированных информационных системах промышленных предприятий // Программные продукты и системы. 2015. № 4. С. 210–218.

11. Дедюхина М.А. Информационная поддержка контроллинга на основе ERP-систем // Вестн. Удмуртского ун-та: Сер. Экономика и право. 2010. № 2-4. С. 22–27

12. Хемраджани А. Гибкая разработка приложений на Java с помощью Spring, Hibernate и Eclipse М.: Вильямс, 2008. 352 с.

13. Лебедева И.Ю., Черный К.Ю. Внедрение СУБД Оracle как одно из направлений инновационной деятельности предприятия // Науч. тр. SWorld. 2010. Т. 17. № 2. С. 17–21.

14. Oracle Fusion Middleware 11g. URL: https://docs.oracle.com/cd/E21764_01/doc.1111/e15020.pdf (дата обращения: 12.11.2017).