Проектная деятельность органов власти Пермского края в реализации государственных программ

СОДЕРЖАНИЕ

Введение

Глава 1. Проектная деятельность в органах власти Пермского края

1.1 Участие органов власти Пермского края в проектной деятельности

.2 Описание процессов проектного управления в органах власти Пермского края

.3 Обзор программных средств управления государственными программами

Выводы по первой главе

Глава 2. Проектирование ИС УГП

2.1 Обзор публикаций по проблеме моделирования бизнес-процессов

.2 Требования к средствам моделирования бизнес-процессов управления проектами

.3 Обзор программных средств моделирования бизнес-процессов

.4 Выбор платформы автоматизации бизнес-процессов с использованием метода вариантных секторов

.5 Анализ автоматизированных процессов жизненного цикла проекта

.6 Требования к реализации процессов управления объектами в ИС УГП

.7 Общие требования к ИС УГП

.8 Функциональные требования

.9 Требования к структуре базы данных

Выводы по второй главе

Глава 3. Взаимодействие ИС УГП с ИАС ПК

3.1 Описание Информационной аналитической системы Пермского края

.2 Интеграционная платформа Highway SB

.3 Состав передаваемых данных

Выводы по четвертой главе

Заключение

Словарь терминов и сокращений

Библиографический список

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

Приложение Б. Описание состава атрибутов модели данных ИС УГП управления государственными программами

Приложение В. Схема процесса разработки объекта управления

Приложение Г. Схема процесса внесения изменений

Приложение Д. Схема процесса отчетности об исполнении вех объекта управления

Приложение Е. Регламент информационного обмена данными между ИС УГП и ИАС ПК

 

 

ВВЕДЕНИЕ

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

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

В соответствии с Постановлением Правительства РФ от 15.10.2016 №1050 «Об организации проектной деятельности в Правительстве Российской Федерации»; устанавливается порядок организации проектной деятельности, который определяет организационную структуру системы управления проектной деятельностью, этапы инициирования, подготовки, реализации, мониторинга и завершения приоритетных проектов (программ). Органам государственной власти субъектов Федерации рекомендовано организовать проектную деятельность на региональном уровне, руководствуясь утверждённым Положением об организации проектной деятельности в Правительстве России.

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

С 2014 года государственные программы реализуются с использованием методов проектного управления. В основе программы всегда лежит несколько проектных кластеров, и программа внедряется как серия проектов.

июня 2014 года Пермский край определен пилотной площадкой первого уровня по внедрению проектного управления в органах государственной власти. Функции проектного офиса исполняет департамент мониторинга Администрации губернатора Пермского края.

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

Как было сказано выше, объектами управления в Пермском крае, отслеживаемых системой проектного управления, являются проекты, программы, непроектные мероприятия, «дорожные карты». В настоящий момент в органах власти Пермского края реализуется 174 объекта управления, из них 40 - проекты, 12 - непроектные мероприятия, 101 - подпрограммы государственных программ и 21 - «дорожные карты».

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

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

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

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

·  Информационно-аналитическая система Пермского края (далее - ИАС ПК).

·        Информационная аналитическая система управления объекта управлениями на базе технологии MS Project (далее - ИАС УП).

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

В ИАС ПК ведется перечень подпрограмм и мероприятий и каждой подпрограмме соответствует перечень целевых показателей. В ИАС ПК ответственные должны отчитываться о ходе достижения целевых показателей. Фактические данные о достижении показателей должны утверждаться заинтересованными сторонами.

ИАС УП является основным инструментом технологической поддержки управления проектной деятельностью.

В составе прикладного программного обеспечения ИАС УП реализованы следующие функциональные возможности:

·  Управление проектами и их портфелями.

·        Автоматизация процессов инициации планирования, реализации, управления изменениями, завершения и контроля проектов.

·        Формирование планов-графиков и паспортов проектов.

·        Отслеживание соблюдения сроков достижения вех, финансов, рисков.

·        Согласование проектной документации и задач процессов.

·        Управление ресурсами, систематизация ресурсов в соответствии с функционально-целевой моделью управления, ведение организационной структуры, реестра пользователей участников проектной деятельности (пользователей ИАС УП) с учетом их проектных ролей и прав доступа.

·        Хранение проектной документации, организация работы с проектным контентом (документами, задачами) и процессами.

·        Формирование оперативной и аналитической отчетности.

·        Информирование участников проектной деятельности о ходе работ над объектами управления с использованием электронной почты и web-приложения.

В ИАС УП размещаются следующие данные:

·  Проектная документация (паспорта и планы-графики) объектов управления, находящаяся на стадии разработки.

·        Планы и отчеты по объектам управления, в том числе завершенным.

·        Шаблоны проектной документации (паспортов и планов-графиков) объектов управления.

·        Методические материалы и инструкции по управлению объектами управления, по эксплуатации ИАС УП.

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

С момента применения к процессу реализации государственных программ методов проектного управления был создан особый тип проекта - подпрограмма государственной программы. В ИАС УП стали размещаться их план-графики, содержащие мероприятия, основные мероприятия и вехи подпрограмм. Отдельно создается список контрольно-целевых показателей с их плановыми и фактическими значениями. Ответственные за достижение показателей и вех должны вовремя актуализировать информацию о ходе выполнения поставленных задач в ИАС УП путем формирования отчётности об исполнении вех календарного плана, о результатах снятия или минимизации рисков, о результатах достижения целевых показателей.

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

Также актуальность работы обусловлена следующими аспектами:

·  Постановление правительства РФ о внедрении проектного управления в органах государственной власти субъектов федерации.

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

·        Участие Пермского края в роли пилотного региона по внедрению проектного управления в реализации государственных программ.

·        Существующая ИАС УП по итогам конкурса «Проектный олимп» признана в числе лучших информационных систем технологической поддержки проектного управления в органах власти. Но она разработана на платформе MS ProjectServer, что противоречит закону об импортозамещении программного обеспечения в органах власти.

Объектом исследования является проектная деятельность органов власти в реализации государственных программ.

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

Цель - проектирование информационной системы управления государственными программами администрации губернатора Пермского края (далее ИС УГП) в соответствии с нормативными требованиями к процессу реализации государственных программ.

Для достижения поставленной цели необходимо решить ряд задач:

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

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

.        Разработать модели действующих процессов управления проектами и проанализировать их.

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

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

.        Разработать регламент информационного взаимодействия ИС УГП и ИАС ПК.

Для решения перечисленных задач использовались методы анализа, моделирования и объектно-ориентированного проектирования,

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

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

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

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

В третьей главе приводится описание возможностей ИАС ПК для интеграции с Системой, описание интеграционной платформы, а также требования к информационному обмену данными между проектируемой системой и ИАС ПК.

В заключении приведены итоги и выводы о проделанной работе.

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

В приложении приводятся практические результаты проделанной работы:

·  Описание типовых функций проектных ролей участников проектной деятельности органов власти и Администрации губернатора Пермского края.

·        Описание атрибутного состава базы данных проектируемой системы и диаграммы классов.

·        Регламент информационного взаимодействия между системой управления государственными программами и ИАС ПК, содержащий детальный атрибутный состав передаваемых данных.

Глава 1.                      
 Проектная деятельность в органах власти Пермского края

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

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

Проектное управление в органах власти и Администрации губернатора Пермского края начало использоваться еще с 2006 года, когда начали внедряться приоритетные проекты и развивается постепенно. Создаются нормативные документы, регламентирующие проектную деятельность, была создана и запущена в промышленную эксплуатацию Информационно-аналитическая системы управления проектами на платформе Microsoft ProjectServer (ИАС УП).

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

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

Параллельно, с внедрением типа проекта «Подпрограмма государственной программы» в Информационно-аналитической системе Пермского края (ИАС ПК) начинается контроль достижения показателей государственных программ. В ИАС ПК ведется перечень подпрограмм и мероприятий и каждой подпрограмме соответствует перечень целевых показателей. В ИАС ПК ответственные так же должны отчитываться о ходе достижения целевых показателей. Фактические данные о достижении показателей так же должны утверждаться заинтересованными сторонами.

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

1.1 Участие органов власти Пермского края в проектной деятельности

Проектное управление в органах власти Пермского края начинает свою историю с 2006 года, когда на территории Пермского края начали реализовываться приоритетные региональные проекты «Новая школа», «Муниципальные дороги», «Качественное здравоохранение», «Достойное жилье», «Содействие в переселении граждан из труднодоступных и отдаленных населенных пунктов», а также отдельные пилотные проекты в сфере развития человеческого потенциала.

В 2007 году была сформирована рабочая группа по развитию системы проектного управления в органах государственной власти и появились первые правовые акты об оформлении проектов (распоряжение губернатора Пермского края №23-р) и реестры проектов. Органы власти были объединены в функционально-целевые блоки и функциональные блоки. Указом губернатора Пермского края №55 для каждого блока были установлены цели, задачи, и проекты, обеспечивающие их реализацию, а также целевые показатели, которые позволяли оценить степень достижения целей и задач.

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

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

В соответствии с распоряжением председателя Правительства Пермского края от 26.01.2011 г. №8-рпп «О Регламенте процесса оперативного планирования по проектам, целевым программам и непроектным мероприятиям на основе технологии Microsoft ProjectServer» все проекты, программы и непроектные мероприятия стали реализовываться с использованием Информационно-аналитической системы управления проектами (далее - ИАС УП).

После утверждения Плана правовым актом, планы-графики стали размещаться в Microsoft Project и оперативное планирование по ним осуществлялось в ИАС УП. Когда было утверждено распоряжение председателя Правительства Пермского края от 31.01.2012 г. №13-рпп «О формировании Плана мероприятий Правительства Пермского края по реализации приоритетных направлений социально-экономического развития Пермского края», План мероприятий стал формироваться в ИАС УП автоматически на основании сохраненных в ИАС УП базовых планов, данная модель формирования Плана мероприятий действует и в настоящее время.

В 2012 году ИАС УП была запущена в промышленную эксплуатацию распоряжением председателя Правительства Пермского края от 13 июня 2012 г. №72-рпп.

В 2009-2012 гг. функции проектного офиса по внедрению проектного управления выполняло аналитическое управление Аппарата Правительства Пермского края.

В октябре 2012 года был сформирован Проектный офис в составе департамента мониторинга Администрации губернатора Пермского края (положение о Проектном офисе утверждено в 2014 г.).

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

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

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

С 1 января 2014 года Пермский край перешел на программный бюджет. Были разработаны и утверждены планы реализации государственных программ, подпрограммы государственных программ стали реализовываться с использованием ИАС УП.

июня 2014 года Пермский край определен пилотной площадкой первого уровня по внедрению проектного управления в органах государственной власти.

В настоящий момент в органах власти Пермского края реализуется 174 объекта управления, из них 40 - проекты, 12 - непроектные мероприятия, 101 - подпрограммы государственных программ и 21 - «дорожные карты». Все объекты размещены в ИАС УП (приостановлены из них 8). При том в Пермском крае реализуется 22 государственные программы.

Участниками проектной деятельности в органах государственной власти Пермского края являются губернатор Пермского края, председатель Правительства Пермского края, руководители функционально-целевых/функциональных блоков, руководители и специалисты ИОГВ Пермского края [17].

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

В целях обеспечения полномочий губернатора в сфере определения стратегии социально-экономического развития Пермского края и направлений ее реализации Администрация губернатора выполняет следующие функции [18]:

·  управляет процессом разработки стратегии и программы социально-экономического развития Пермского края, включая подготовку и обоснование принципов социально-экономического развития и контроль их исполнения;

·        управляет процессом подготовки программы социально-экономического развития Пермского края;

·        осуществляет мониторинг результативности плана мероприятий Правительства Пермского края по социально-экономическому развитию Пермского края;

·        по результатам реализации плана мероприятий Правительства Пермского края по социально-экономическому развитию Пермского края и программы социально-экономического развития Пермского края готовит рекомендации для внесения корректировок в соответствующие документы;

·        организует подготовку ежегодных посланий губернатора о социально-экономическом и политическом положении в Пермском крае;

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

В целях обеспечения полномочий губернатора в сфере определения целей и задач деятельности исполнительных органов государственной власти Пермского края, в рамках реализации приоритетных направлений развития Пермского края и стратегических программных мероприятий и осуществления контроля за достижением целевых показателей Администрация губернатора Пермского края [18]:

·  управляет процессом планирования целей, задач и целевых показателей деятельности Правительства Пермского края по социально-экономическому развитию Пермского края;

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

·        обеспечивает подготовку документов, аналитических материалов и соответствующих проектов актов губернатора, определяющих цели, задачи и целевые показатели деятельности Правительства Пермского края;

·        организует мониторинг и контроль достижения плановых значений целевых показателей деятельности исполнительных органов государственной власти Пермского края, выполнения проектов и программ, характеризующих исполнение программы социально-экономического развития Пермского края;

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

1.2 Описание процессов проектного управления в органах власти Пермского края

Процесс управления проектами в органах власти Пермского края состоит из следующих групп процессов:

·  Инициация проекта.

·        Планирование проекта.

·        Исполнение проекта.

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

·        Контроль проекта.

·        Завершение проекта.

Основными инструментами управления проектами являются паспорт, план-график, планы и отчеты по ним.

Основным инструментом технологической поддержки управления «дорожными картами», проектами, программами, непроектными мероприятиями является ИАС УП.

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

1.2.1  Организационная структура и роли участников проектного управления

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

К таким подразделениям относится:

·  Межведомственная комиссия по планированию социально-экономического развития Пермского края (далее - МВК по СЭР ПК).

·        Проектный офис Администрации губернатора Пермского края.

·        Ответственных за проектное управление функционально-целевых/функциональных блоков.

·        Ответственных за проектное управление в ИОГВ.

·        Проектные команды (проектные офисы, рабочие группы) объектов управления ИОГВ.

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

Организационная структура проектного управления представлена на рис. 1.1.

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

Рисунок 1.1 Организационная структура специализированных структурных подразделений

В ходе анализа проектной деятельности органов власти и Администрации губернатора Пермского края были выделены следующие проектные роли:

·  Заказчик - Губернатор Пермского края или иной руководитель органа власти.

·        Руководитель функционально-целевого/функционального блока.

·        Ответственный за проектное управление функционально-целевого/функционального блока.

·        Руководитель ИОГВ.

·        Ответственный за проектное управление в ИОГВ.

·        Руководитель «дорожной карты», проекта, программы, непроектного мероприятия - это участник проекта, которому делегированы полномочия по управлению деятельностью, направленной на достижение целей проекта. Руководитель проекта несет ответственность перед заказчиком за достижение всех целей проекта.

·        Администратор «дорожной карты», проекта, программы, непроектного мероприятия - участник проекта, отвечающий за организацию процесса планирования проекта, подготовку отчетности по проекту, сопровождение согласования и ведение проектной документации, ведение архива проекта, организацию совещаний по проекту, ведение протоколов и оказание иной административной поддержки руководителю проектов.

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

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

Схема взаимодействия участников проектной деятельности в ИОГВ Пермского края изображена на рис. 1.2.

Описание типовых функций проектных ролей приведено в Приложении А.

Рисунок 1.2 Роли участников проектной деятельности

1.2.2  Описание процессов управления проектами

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

Рисунок 1.3 Схема жизненного цикла проекта

Каждый этап (стадия) проекта функционирует в рамках определенного процесса.

Процессы управления проектами разделяются на пять групп:

·  Группа процессов инициации - процессы, которые выполняются для определения нового проекта или новой фазы существующего проекта путем получения разрешения для начала проекта или фазы.

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

·        Группа процессов исполнения - процессы, применяемые для выполнения работ, определенных в плане управления проектом, для удовлетворения спецификаций проекта.

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

·        Группа процессов завершения - процессы, выполняемые для завершения всех действий в рамках всех групп процессов и формального завершения проекта или фазы.

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

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

На этапе планирования проекта проводится разбиение проекта на отдельные блоки работ и выделение мероприятий и контрольных событий в следующих разрезах:

·  Отчетные периоды (неделя, месяц, квартал, год).

·        Этапы проекта.

·        Весь проект.

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

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

Контроль исполнения проекта осуществляется с использованием отчетности с периодичностью, определенной типом проекта. Установленные периоды отчетности позволяют осуществлять контроль на всех уровнях: стратегическом (1 раз год), тактическом (1 раз в квартал), оперативном (1 раз в месяц), операционном (1 раз в неделю).

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

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

1.3     Обзор программных средств управления государственными программами

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

Так, Департаментом информационных технологий г. Москвы используется «Информационная система управления Государственными программами», разработанная компанией «Проектная практика» на платформе MS SharePoint.

К функциональным возможностям системы относятся:

·  Сбор и/или формирование заявок органов исполнительной власти г. Москвы на автоматизацию/модернизацию/развитие (основание для инициации проектов).

·        Включение проектов в План работ по информатизации, в том числе согласование объемов финансирования.

·        Ведение паспортов проектов.

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

·        Учет финансовых показателей проектов.

·        Хранение документации по проектам.

·        Назначение на роли участников проектов.

·        Формирование отчетов о ходе реализации проектов и об исполнительской дисциплине в утвержденных формах.

·        Оповещение участников о событиях в проекте.

·        Мониторинг целевых показателей проектов.

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

·  Разработка паспорта.

·        Формирование и актуализация календарного плана.

·        Контроль сроков.

·        Управление ресурсами программы.

·        Управление рисками.

ИАС УП Департамента обеспечивает доступ пользователей через Web-интерфейс с возможностью разграничения прав доступа по ролям, поиск информации, формирование электронных форм (карточек) проектов, выгрузку информации во внешние форматы и т.п. [11]. Основным недостатком этой системы является использование иностранного программного обеспечения.

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

Функциональные возможности «ПМ Форсайт» достаточно обширны, т.к. система модульная.

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

Разработчики системы управления проектами «Адванта» предлагают «Систему управления целевыми программами» - решение, специально разработанное для органов власти. Это решение предоставляет возможности для планирования и контроля проектов, организации межведомственного взаимодействия и контроля целевых показателей [21].

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

Выводы по первой главе

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

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

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

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

2.
Проектирование ИС УГП

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

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

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

2.1 Обзор публикаций по проблеме моделирования бизнес-процессов

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

В ГОСТе Р ИСО 9000-2008 под процессом понимается «любая деятельность, в которой используются ресурсы для преобразования входов в выходы» [6].

В.В. Репин и В.Г. Елиферов в своей книге дают следующее определение: «Бизнес-процесс - устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя» [13].

Несколько иное определение бизнес-процесса дает И.Г. Федоров: «совокупность работ, направленную на получение воспроизводимого, повторяемого результата» [21]. Т.е. упор в данном случае делается на повторяемость продукта процесса. Но данное определение не противоречит предыдущему, а дополняет его.

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

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

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

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

Например, Р.С. Севастьянов в своем исследовании [14] уделяет внимание проблеме анализа и моделирования бизнес-процессов органов Федерального казначейства и рассматривает вопросы создания и использования имитационной модели для анализа эффективности процессов с применением процедур визуального и имитационного моделирования на основе языка UML и программного средства СИМ-UML. Данная программная система предназначена для анализа и моделирования деловых процессов организации, реализующая принцип интеграции визуального и имитационного моделирования [22].

Н.А. Боков отмечает, что при разработке и внедрении информационных систем телекоммуникационных компаний целесообразнее использовать методику eT-счетов (extended T-accounts), т.к. существующие методологии и соответствующие нотации - IDEF0, IDEF3, DFD, eEPC - не позволяют явно описать и наглядно представить учетные схемы предприятия для всех участников проекта создания и внедрения корпоративной информационной системы. Нотация еТ-счетов представляет собой графический язык и инструментарий для моделирования финансовой деятельности компании. Моделирование бизнес-процессов с использованием данной нотации обеспечивает прозрачность отражения хозяйственных операций, благодаря чему позволяет создать единую модель учета операций. Кроме того, нотация еТ-счетов дает возможность отражать в корпоративной информационной системе бухгалтерские проводки в различных системах учета, материальные проводки, а также бюджетные проводки для целей контроля бюджета [2].

Г.А. Благодатский в своих исследования обосновал возможность применения процессного и системного подходов к внутренним бизнес-процессам предприятий с использованием UML-моделей, которые успешно интегрируют предметные области знаний за счет своей наглядности и поддержки технологий объектно-ориентированного проектирования, что позволяет эффективно применять ее для создания модели единой информационной среды предприятия [1].

И.В. Червенчук обосновывает актуальность использования средств объектно-ориентированного анализа для описания бизнес-процессов и разработки информационных систем [24] с целью моделирования бизнес-процессов за счет расширенных элементов языка бизнес-прецедент и бизнес-актер. С помощью этих элементов языка UML становится возможным анализ и моделирование процессов и плавный переход к непосредственной разработке базы данных и информационной системы в целом.

Среди публикаций и контента в сети Интернет не были найдены исследования или статьи о применении методов для автоматизации процессов управления проектами. Взять за основу один из перечисленных не предоставляется возможным. Поэтому принято решение для моделирования и автоматизации процессов в системе управления государственными программами использовать нотацию BPMN, т.к. она предназначена как для моделирования бизнес-процессов, так и для их исполнения, она наиболее современная и активно развивающаяся. Кроме этого нотация позволяет представить процесс настолько детально, насколько это необходимо [5].

2.2  Требования к средствам моделирования бизнес-процессов управления проектами

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

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

·  Дизайнер для моделирования бизнес-процессов с использованием стандартов моделирования. Предпочтение отдается стандарту BPMN.

·        Простой графический интерфейс.

·        Репрезентативность моделей.

·        Русскоязычный интерфейс (желательно).

·        Web-интерфейс.

·        Наличие пользовательской документации.

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

·        Механизм исполнения.

·        Возможности быстрого изменения бизнес-процессов.

·        Возможность контроля каждого экземпляра процесса.

·        Простота в освоении.

·        Полностью opensource.

2.3     Обзор программных средств моделирования бизнес-процессов

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

·  Bizagi BPM Suite.

·        ELMA BPM.

·        Bonita Open Solution.

·        jBPM.

Перечисленные системы моделирования достаточно популярны и востребованы, поддерживают стандарт BPMN.

2.3.1  Bizagi BPM Suite

Система Bizagi BPM Suite состоит из компонентов, выполняющих отдельные функции:

·  Bizagi Process Modeler - дизайнер процессов.

·        Bizagi Studio - инструмент для автоматизации процесса.

·        Bizagi BPM Server - продукт для исполнения процесса.

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

Есть возможность коллективного проектирования. Готовая модель процесса загружается в Bizagi Studio, где можно указать всю информацию, нужную для автоматизации процесса. Модуль позволяет интегрировать систему с прочими корпоративными приложениями.

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

В веб-интерфейсе выполняются пользовательские задачи и производится контроль исполнения процесса.

Bizagi дает возможность обмена моделями между приложениями, поддерживается импорт и экспорт в форматы XPDL и MS Visio.agi BPMS является системой с закрытым кодом. «Облачный» вариант системы отсутствует. Однако Bizagi Process Modeler - дизайнер бизнес-процессов распространяется бесплатно.

Одним из недостатков системы является то, что Bizagi BPM Suite испанская разработка, и в России у компании нет официального представительства [15].

2.3.2  ELMA BPM

ELMA BPM - разработка российской компании ELMA, предназначенная для управления бизнес-процессами.

Моделирование бизнес-процессов в системе ELMA осуществляется в графическом редакторе «Дизайнер ELMA» в нотации BPMN 2.0.

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

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

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

Еще одним плюсом является пошаговая отладка процессов, сценариев и пользовательских форм [25].

2.3.3  Bonita Open Solution

Bonita Open Solution - инструмент моделирования французских разработчиков, не имеющий российской локализации.

Решение состоит из трёх основных компонентов, разделенных по назначению:

·  Studio - редактор бизнес-процессов.

·        Execution Engine - инструмент для исполнения бизнес-процессов.

·        User Experience - интерфейс для взаимодействия с развернутыми бизнес-процессами и управление ими.

К основным функциям платформы относится:

·  Создание бизнес-процессов из элементарных шагов.

·        Создание переменных для доступа, манипуляций и управления данными в бизнес-процессе.

·        Создание цепочек бизнес-процессов.

·        Назначение ролей и исполнителей на роли в бизнес-процессе.

Моделирование процессов Bonita Open Solution происходит в нотации BPMN.

К достоинствам Bonita Studio относится моделирование и автоматизация процесса в одном окне и высокая степень визуализации бизнес-процессов/

Однако в Bonita Open Solution отсутствует поддержка динамического изменения бизнес- процесса, хотя возможность изменения процесса во время его исполнения входит в число ключевых концепций управления бизнес- процессами. К тому же есть проблемы с использованием русского языка в системе, то есть если название процесса написать русскими символами, он не находится при запуске [8].

2.3.4  jBPM

JBPM означает «Java Business Process Management». Это платформа на Java от компании JBoss для реализации потоков рабочих процессов, формализованных с помощью языка BPEL или собственного языка описания процессов jPDL. Выпускается под лицензией LGPL [26].

Его наиболее заметные признаки перечислены ниже:

·  Настраиваемый, встраиваемый, легковесный редактор процессов.

·        Домен ориентированные процессы и правила.

·        Независимый сервис управлением поручениями.

·        Веб интерфейс позволяет создавать BPMN2 процессы, разворачивать, управлять; строить отчеты (BIRT), управлять поручениями.

·        Сохранение состояния процесса в его промежуточной точке.

·        Возможность асинхронного исполнения процессов.

·        Версионность описания процесса.

·        Заведение в системе пользователей, назначение им заданий.

·        Поддержка рассылки e-mail сообщений о назначении пользователям заданий.

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

·        Возможность использования скриптового языка jUEL.

·        Запуск как отдельным приложением, так и внутри приложения.

·        Возможность отслеживания каждого экземпляра процесса.

2.4 Выбор платформы автоматизации бизнес-процессов с использованием метода вариантных секторов

Для выбора программного средства моделирования будет применен метод вариантных секторов. Суть метода заключается в сравнении вариантов - программных средств - по выбранным критериям. Составляется таблица, в которой строки - это варианты программных продуктов, а столбцы - перечисленные критерии. Далее каждому средству моделирования проставляется оценка из диапазона [-10; 10] в зависимости от степени выраженности свойства. После этого определяется вес критерия и производится расчет значений. Результаты вычислений приведены в табл. 2.1.

Таблица 2.1

Сравнительный функциональный анализ программных средств моделирования бизнес-процессов

	Вес критерия	Bizagi BPM Suite	ELMA BPM	Bonita Open Solution	jBPM
Простой графический интерфейс.	7	8	8	5	10
Русскоязычный интерфейс.	7	8	6	0	0
Web-интерфейс	10	0	0	0	10
Наличие пользовательской документации.	8	5	2	3	6
Возможность задавать различные специфические технические аспекты процесса - продолжительность транзакции, сообщения и уведомления в рамках процесса, и проектировать интерфейсы взаимодействия с другими системами.	10	10	8	3	8
Механизм исполнения.	10	10	8	3	10
Средства контроля и мониторинга выполнения бизнес-процессов;	9	10	8	5	10
Возможности быстрого изменения бизнес-процессов	6	8	6	10
Простота в освоении.	6	7	6	2	10
Полностью opensource	10	5	5	5	10
Рейтинг		594	480	262	708

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

2.5     Анализ автоматизированных процессов жизненного цикла проекта

Как было сказано выше, для автоматизации жизненного цикла проектов в ИАС УП реализованы бизнес-процессы управления проектами. Ниже приводится их описание, анализ и рекомендации по модернизации.

2.5.1  Инициация объекта управления

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

Руководитель функционально-целевого/функционального блока принимает решение о формализации предложений инициатора для рассмотрения на межведомственной комиссии по планированию СЭР ПК.

Межведомственная комиссия по планированию СЭР ПК рассматривает формализованное предложение о необходимости реализации объекта управления. В случае положительного решения о реализации объекта управления определяет уровень контроля и тип объекта управления (подпрограмма, проект, «дорожная карта», непроектное мероприятие).

Руководитель ИОГВ, ответственного за достижение результатов проекта правовым актом назначает Руководителя и Администратора «дорожной карты», проекта, программы, непроектного мероприятия.

Завершающим этапом процесса инициации является регистрация объекта управления в ИАС УП.

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

Т.к. процесс инициации в ИАС УП заключается только в заполнении и сохранении заявки на регистрацию проекта, принято решение при моделировании объединить его с процессом планирования и согласования.

2.5.2  Планирование и согласование объекта управления

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

Процесс планирования проекта предполагает:

·  Ввод сведений о проекте.

·        Разработку иерархической структуры задач плана-графика проекта по выбранному шаблону.

·        Планирование сроков.

·        Планирование ресурсов (исполнителей и ответственных по задачам).

·        Ввод данных о финансировании в разрезе источников.

·        Занесение рисков проекта.

·        Определение контрольных событий проекта.

·        Формирование списка лиц, согласующих проектную документацию.

·        Согласование проектной документации.

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

Разработка проекта включает в себя ввод сведений о проекте и планирование работ, ресурсов, рисков с использованием приложения Microsoft Project Professional.

Форма задачи по разработке содержит модуль «Мастера разработки», который позволяет пошагово занести необходимую информацию о проекте в ИАС УП.

Разработка проекта начинается с заполнения раздела «Сведения о проекте», на основе данных которого автоматически формируется Паспорт проекта.

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

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

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

Отдельным пунктом Мастера разработки является занесение рисков (вопросов) проекта, которые связываются с мероприятиями, подверженными их влиянию. Для рисков определяется их содержание, уровень, вероятность наступления, ожидаемая дата наступления, варианты снятия и минимизации, ответственные за работы по снятию и минимизации риска. Планирование рисков происходит с использованием веб-формы карточки риска.

Результатом процесса планирования реагирования на риски являются:

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

·        Установление степени вероятности наступления риска.

·        Установление связи риска с результатом (результатами), который (-ые) могут быть не достигнуты в случае наступления риска.

·        Определение вариантов снятия/минимизации риска (планы реагирования на риск) и оценочной стоимости снятия/минимизации риска.

·        Определение ответственного за работу по снятию/минимизации риска.

·        Включение в План-график упреждающих задач (работ) по реагированию на риск.

После завершения предыдущих шагов становится возможным формирование проектной документации - Паспорт и План-график проекта - на основе занесенных данных.

Паспорт проекта формируется автоматически по утвержденной форме на основании занесенных в ИАС УП сведений о проекте, реестра рисков, а также блоков работ и вех из Плана-графика.

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

План-график и Паспорт проекта запускается на согласование в ИАС УП Руководителем после прохождения технической экспертизы.

Согласование проекта осуществляется путём последовательного назначения задач по согласованию проекта всем лицам, указанным в списке согласующих проекта.

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

После завершения доработки проект снова переходит на стадию согласования.

Утверждение Плана-графика и Паспорта осуществляется Заказчиком в ИАС УП после согласования всеми согласующими.

После утверждения проектной документации в ИАС УП Заказчиком Системным администратором ИАС УП сохраняется Базовый план, проект переходит на стадию исполнения.

Таким образом, процесс инициации и разработки проекта проходит в несколько этапов:

.   Создание заявки на регистрацию проекта

.   Планирование проекта

3.      Согласование проекта

.        Доработка проекта (при необходимости)

.        Завершение процесса

Участниками процесса являются:

·  Инициатор - пользователь заполнивший заявку на регистрацию проекта в ИАС УП.

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

·        Администратор системы - сотрудник службы технической поддержки.

·        ИАС УП.

В ходе анализа процесса инициации и разработки было выявлены следующие недостатки:

.   После сохранения заявки на регистрацию проекта инициация процесса планирования и согласования происходит в течение 25-30 мин, что недопустимо, т.к. вызывает негативное отношение пользователя, ответственного за размещение проекта в ИАС УП.

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

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

Модель процесса AS IS с обозначенными проблемными местами приведена на рис. рис. 2.1. Проблемные блоки выделены красным цветом.

На рис. 2.2 приведена модель процесса TO BE.

2.5.3  Исполнение проекта

Целью процесса исполнения проекта является актуализация данных о результатах реализации проекта. Процесс исполнения проекта предполагает:

·  Ввод исполнителем фактических данных об исполнении вех и запуск процесса реализации.

·        Согласование внесенной информации заинтересованными сторонами.

·        Актуализация фактических данных об исполнении вех в плане-графике проекта.

Рисунок 2.1 Модель процесса инициации и разработки проекта AS IS с выделенными проблемными блоками

Рисунок 2.2 Модель процесса инициации и разработки проекта TO BE

Участниками процесса являются:

·  Инициатор - пользователь, ответственный за достижение вехи.

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

·        ИАС УП.

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

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

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

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

В ходе анализа процесса реализации были выявлены следующие недостатки:

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

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

Модель процесса AS IS на рис. 2.3. Проблемные блоки выделены красным цветом.

На рис. 2.4. приведена модель процесса TO BE.

Рисунок 2.3 Модель AS IS процесса реализации с выделенными проблемными блоками

Рисунок 2.4 Модель TO BE процесса реализации

2.5.4  Управление изменениями проекта

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

Процесс управления изменениями предполагает:

·  Формирование запросов на изменение проектной документации исполнителями проектов.

·        Согласование запросов с заинтересованными сторонами.

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

·        Согласование внесенных изменений.

В перечень участников процесса входят:

·  Инициатор - исполнитель проекта, ответственный за изменение его данных.

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

·        Администратор системы - сотрудник службы технической поддержки.

·        ИАС УП.

Процесс «Управление изменениями» предусматривает формирование запросов на изменение проектной документации исполнителями проектов и обеспечивает согласование запросов с заинтересованными сторонами.

В ИАС УП реализованы согласование и отклонение запроса на доработку, его редактирование и повторный запуск согласования изменений.

Основанием для внесения изменений в План-график и Паспорт проекта является изменение исходных данных и условий, на основе которых осуществлялась подготовка проекта.

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

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

Внесенные изменения должны пройти процедуру согласования заинтересованными сторонами, определенными на этапе формирования запроса на изменение.

После согласования внесенных изменений предусмотрено сохранение новой версии базового плана администратором системы.

Кроме этого процесс «Управление изменениями» в ИАС УП предназначен и для завершения или приостановки проекта, в ходе которого происходит смена статуса проекта на указанный в запросе и перенос его в архив проектов.

Процесс завершения предполагает:

·  Формирование запроса на изменение статуса проекта Руководителем проекта.

·        Согласование запроса с заинтересованными сторонами.

·        Изменение статуса проекта.

·        Согласование внесенных изменений.

·        Перенос проекта в архив проектов.

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

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

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

Только после этого система меняет статус проекта на указанный в запросе инициатором.

В ходе анализа процесса «Управление изменениями» было выявлены следующие недостатки:

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

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

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

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

На рис. 2.5 и рис. 2.6 приведены модели AS IS и TO BE процесса «Управления изменениями» проекта.

Рисунок 2.5 Модель AS IS процесса «Управление изменениями» с выделенными проблемными блоками

Рисунок 2.6 Модель TO BE процесса «Управление изменениями»

2.6 Требования к реализации процессов управления объектами в ИС УГП

В результате анализа действующих в ИАС УП процессов управления проектами с учетом рекомендаций были разработаны требования к реализации следующих процессов в Системе управления государственными программами:

·  Разработка/доработка и согласование объекта управления.

·        Исполнение объекта управления.

·        Внесение изменений в объект управления.

2.6.1  Требования к реализации процесса «Разработка/доработка и согласование объекта управления»

Процесс разработки/доработки и согласования объекта управления (далее - процесс) предназначен для внесения и согласования данных объекта управления.

Процесс состоит из следующих этапов:

.   Создание заявки на регистрацию объекта управления.

.   Разработка объекта управления.

3.      Техническая экспертиза.

.        Согласование объекта управления.

.        Доработка объекта управления (при необходимости).

.        Завершение процесса.

Требования к этапу создания заявки на объект управления

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

При добавлении новых объектов управления любого типа должна быть реализована возможность заполнения заявки на регистрацию. Заявка должна вызываться из раздела «Реестр объектов» путем нажатия кнопки «Создать». На форме заявки пользователь должен иметь возможность:

·  Указать тип создаваемого объекта управления.

·        Ввести полное наименование объекта управления.

·        Указать руководителя объекта управления из списка пользователей ИС УГП.

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

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

Требования к этапу разработки объекта управления

При запуске процесса разработки объекта управления необходимо передать данные объекта управления и данные с формы заявки и инициализировать переменные процесса:

·  Дата начала равна текущей дате.

·        Кем создан: = Инициатор процесса.

·        ID объекта - идентификатор объекта управления.

·        Исполнитель - пользователь, указанный как Руководитель объекта на форме заявки.

·        i :=1 - текущая строка в списке согласующих

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

При назначении задачи должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.

Так же ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета

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

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

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

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

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

Требования к этапу технической экспертизы

После завершения этапа разработки объекта управления должен осуществляться оперативный контроль внесенных данных - техническая экспертиза.

Задача «Подготовить заключение о соответствии техническим требованиям» поступает сотруднику департамента мониторинга Администрации Губернатора Пермского края, для которого в учетных данных определена роль «Техническая экспертиза».

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

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

При назначении задачи должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.

Так же ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета.

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

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

Если форма исполнения задания выбрана «Согласовано», происходит переход на этап согласования объекта управления.

Требования к этапу согласования объекта управления

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

Дополнительные согласующие выбираются на странице Участники объекта управления в блоке Соисполнители.

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

После завершения согласования с дополнительными начинается согласование с обязательными согласующими.

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

Обязательными согласующими для типов действия «дорожная карта», проект, непроектное мероприятие являются:

Если Заказчиком объекта управления является Губернатор Пермского края:

.   Руководитель органа власти, указанного Ответственным исполнителем (Project.Doer.Head).

.   Руководители органов власти, сфера деятельности которых затрагивается при реализации «дорожной карты», проекта, программы или непроектного мероприятия (соисполнители) (Project.Stakeholder.OrganizationUnit.Head, у которых Project.Stakeholder.ProjectRole = Соисполнитель).

3.      Переход на следующую стадию согласования осуществляется только после завершения задач по согласованию всеми руководителями ИОГВ соисполнителей.

.        руководители функционально-целевых/функциональных блоков, сфера деятельности которых затрагивается при реализации «дорожной карты», объекта управления, программы или непроектного мероприятия - руководители ФЦБ, в которые входят органы власти, выбранные соисполнителями. (Project.Stakeholder.OrganizationUnit.Hierarhy.Head, у которых Project.Stakeholder.ProjectRole = Соисполнитель).

5.      Переход на следующую стадию согласования осуществляется только после завершения задач по согласованию всеми руководителями ФЦБ соисполнителей

.        Председатель Правительства Пермского края (Project.OrganizationUnit.Head, OrganizationUnitName = Председатель Правительства Пермского края).

.        Руководитель департамента мониторинга Администрации губернатора Пермского края (Project.OrganizationUnit.Head, если OrganizationUnitName = Департамент мониторинга Администрации губернатора Пермского края).

.        Заместитель руководителя Администрации губернатора Пермского края, (Project.OrganizationUnit.Head).

.        Заказчик (Губернатор Пк) (Project.Customer)

Если Заказчиком объекта управления является не Губернатор Пермского края, список обязательных согласующих должен формироваться следующим образом:

.   Руководитель органа власти, указанного Ответственным исполнителем (Project.Doer.Head).

.   Руководитель департамента мониторинга Администрации губернатора Пермского края (Project.OrganizationUnit.Head, если OrganizationUnitName = Департамент мониторинга Администрации губернатора Пермского края).

3.      Заместитель руководителя Администрации губернатора Пермского края, (Project.OrganizationUnit.Head).

Обязательным согласующим объект управления с типом «Непроектное мероприятие по привлечению федеральных финансовых средств» является определенный сотрудник департамента мониторинга Администрации Губернатора Пермского края. (OrganizationUnitName=департамент мониторинга Администрации губернатора Пермского края.)

Обязательным согласующим для Подпрограмм государственных программ является руководитель органа власти, указанного Ответственным исполнителем (Project.Doer.Head).

Обязательным согласующим Государственных программ является руководитель департамента мониторинга Администрации губернатора Пермского края (Project.OrganizationUnit.Head, если OrganizationUnitName = Департамент мониторинга Администрации губернатора Пермского края).

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

При назначении задачи должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.

Так же ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета.

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

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

Этап согласования объекта управления длится до тех пор, пока количество согласовавших (со статусом «Согласовано») не будет равно количеству согласующих в списке.

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

Требования к этапу доработки объекта управления

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

При назначении задачи на доработку объекта управления должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.

Так же ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета.

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

Перенаправление задачи происходит аналогично с разработкой объекта управления.

Если форма исполнения задания выбрана «Выполнено» происходит переход на этап согласования объекта управления. Задача назначается первому согласующему в списке согласования.

После завершения этапа согласования объекта управления (согласовали все пользователи из списка согласующих со статусом «Согласовано») процесс переходит на этап завершения.

Требования к этапу завершения процесса разработки/доработки и согласования объекта управления

На этапе завершения процесса Система должна выполнить следующие операции:

.   Присвоить значение Project.Status: = Исполнение.

.   Присвоить значение Project.Stage: = Исполнение.

3.      Сохранить базовый план объекта - для каждого экземпляра Task:

3.1 Значение атрибута BaseStart принимает значение, равное PlannedStart.

3.2    Значение атрибута BaseFinish принимает значение, равное PlannedFinish.

3.3 Значение атрибута BaseDuration принимает значение, равное PlannedDuration.

Далее процесс разработки/доработки и согласования объекта управления завершается и объект переходит на стадию реализации.

Схема исполняемой модели процесса разработки объекта управления приведена в Приложении В.

Требования к реализации процесса «Отчетность по исполнению»

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

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

.   Сотрудник департамента мониторинга Администрации губернатора Пермского края, курирующий реализацию объекта управления - Project.Doer.Куратор.

    Руководитель ИОГВ-ответственного исполнителя - Project.Doer.Head.

Требования к этапу инициации отчетности по исполнению

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

При занесении фактических данных пользователю должен иметь возможность:

·  Указать факт исполнения вехи - «Выполнено» или «Не выполнено».

·        Прикрепить к форме отчетности документы, подтверждающие достижение вехи.

·        Внести развернутый комментарий.

·        Если выбрано «Не выполнено», указать степень влияния отклонения срока выполнения вехи на результат объекта управления: «Отклонение критично», «Отклонение не критично», «Своевременное выполнение»,

·        Дата предполагаемого исполнения в случае формирования отчетности со значением «Не выполнено».

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

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

Требования к этапу согласования отчетности по исполнению

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

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

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

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

Пользователь должен указать дополнительных согласующих по порядку согласования.

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

После завершения согласования с дополнительными начинается согласование с обязательными согласующими.

Обязательные согласующие для типов объектов дорожная карта, проект (внутренний, внешний, приоритетный), непроектное мероприятие, подпрограмма государственной программы:

·  Куратор (определяется в зависимости от Ответственного исполнителя объекта управления).

·        Руководитель ИОГВ, являющийся Ответственным исполнителем (Project.Doer.Head).

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

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

При назначении задачи по согласованию фактических данных должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.

Также ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета.

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

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

В момент назначения задачи по согласованию фактических данных ProgressApproval.Status принимает значение OnApproval. Запись появляется в списке истории согласования.

По завершении задачи исполнителем значение поля «Форма исполнения задачи» необходимо передать в ProgressApproval.Status, а значение поля «Дата фактического завершения» задачи в поле ProgressApproval.ApproveTime.

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

Необходимо записать в ProgressApproval.Status: = Approved, в ProgressApproval.Description передать значение поля «Комментарий» формы задачи по согласованию фактических данных.

Этап согласования объекта управления длится до тех пор, пока количество согласовавших (со статусом «Согласовано») не будет равно количеству согласующих в списке.

Если форма исполнения задания выбрана «Отклонено», цикл согласования прерывается. Необходимо записать в ProgressApproval.Status := Отклонено.

Если фактические данные по вехам были отклонены, к следующему согласующему (при его наличии) в списке они поступать не должны.

Если форма выполнения выбрана «Перенаправить» должно появиться поле для выбора другого исполнителя задачи из реестра пользователей ИС УГП.

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

·  В поле Assignment.PercentComplete передать значение ProgressReport.PercentComplete.

·        Если ProgressReport.PercentComplete = 100, то в поле Assignment.ActualStart и Assignment.ActualFinish передать значение ProgressReport.SentTime.

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

Схема процесса приведена в Приложении Д.

Требования к реализации процесса «Внесение изменений в проект»

Процесс внесения изменений в проект (далее - процесс) предназначен для согласования и внесения изменений в проекты.

Процесс состоит из следующих этапов:

.   Инициация процесса изменения.

    Согласование запроса на изменение.

6       Доработка (в случае необходимости) запроса на изменение.

         Внесение изменений.

         Согласование внесенных изменений.

         Доработка (в случае необходимости) внесенных изменений.

         Завершение процесса изменения

Требования к этапу инициации процесса внесения изменений в проект.

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

В момент инициации процесса внесения изменений в объект необходимо проверить наличие процесса внесения изменений со статусом не равным «Завершен» по данному проекту. Если такой процесс существует, Система должна выводить предупреждение о наличии незавершенного процесса и возможности инициировать новый только после его завершения.

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

Форма запроса на изменение должна содержать:

·  Обязательные для заполнения поля:

o Описание вносимых изменений

o   Прикрепление документов, подтверждающих вносимые изменения.

·  Должна быть возможность выбрать дополнительных согласующих.

Требования к этапу согласования запроса на внесение изменений в объект управления

После отправки запроса, стартует процесс внесения изменений.

При запуске процесса необходимо передать данные объекта управления и данные с формы заявки и инициилизировать переменные:

·  Дата начала - дата и время сохранения запроса.

·        Статус процесса := Согласование запроса на изменение.

·        Срок согласования

·        Кем создан := Инициатор процесса

·        i :=1 - текущая строка в списке согласующих

Первым этапом согласования запроса на внесение изменений в проект является согласование запроса (Назначается задача «Согласуйте запрос на внесение изменений в объект управления»).

Определение проверяющего запрос для типов объектов управления «дорожная карта», проект, непроектное мероприятие, государственная программа, подпрограмма осуществляется следующим образом:

·  Руководитель департамента мониторинга Администрации губернатора Пермского края (Project.Stakeholder.OrganizationUnit.Head, если OrganizationUnitName = департамент мониторинга Администрации губернатора Пермского края).

Обязательным согласующим для объекта с типом «Непроектное мероприятие по привлечению федеральных финансовых средств» является:

·  Определенный сотрудник департамента мониторинга Администрации Губернатора Пермского края. (OrganizationUnitName = департамент мониторинга Администрации губернатора Пермского края).

Исполнитель задачи по согласованию запроса должен иметь возможность перенаправить, вернуть на доработку, отклонить или согласовать запрос.

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

Далее происходит назначение задачи по проверке запроса на изменение пользователю, указанному при перенаправлении задачи.

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

Если форма исполнения задания выбрана «Отклонено», создателю запроса должно прийти уведомление об отклонении запроса на внесение изменений в объект. Процесс внесения изменений завершается.

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

Этап согласования объекта управления длится до тех пор, пока количество согласовавших (со статусом «Согласовано») не будет равно количеству согласующих в списке.

Дополнительные согласующие выбираются на этапе заполнении запроса на внесение изменений.

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

При назначении задачи должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.

Так же ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета.

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

Если на форме запроса на внесение изменений был выбран пункт «Необходимо изменить статус объекта управления», после цикла проверки и согласования запроса, задача на внесение изменений пользователю назначаться не должна. В рамках процесса должен изменяться статус объекта управления на статус, выбранный в поле «Новый статус объекта управления». После чего процесс внесения изменений завершается. Инициатору запроса на внесение изменений на e-mail приходит уведомление о завершении процесса.

Требования к этапу доработки запроса на внесение изменений в проект

Если запрос на внесение изменений был отправлен согласующим на доработку, Исполнителю, который внес запрос поступает задача «Доработать запрос на внесение изменений в проект». При назначении задачи должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.

Так же ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета

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

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

Далее происходит назначение задачи по доработке запроса на внесение изменений в проект пользователю, указанному при перенаправлении задачи.

Если форма исполнения задания выбрана «Выполнено», запрос на внесение изменений в проект снова отправляется на круг согласования.

Требования к этапу внесения изменений в проект

Задача на внесение изменений назначается инициатору процесса - автору запроса на изменение.

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

При назначении задачи должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.

Так же ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета.

Исполнитель задачи по внесению изменений в проект должен иметь возможность перенаправить ее или выполнить самостоятельно.

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

Далее происходит назначение задачи по внесению изменений в проект пользователю, указанному при перенаправлении задачи.

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

Требования к этапу технической экспертизы

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

Задача «Подготовить заключение о соответствии техническим требованиям» поступает сотруднику департамента мониторинга Администрации Губернатора Пермского края (пользователю «Техническая экспертиза»).

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

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

При назначении задачи должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.

Так же ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета.

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

Если форма исполнения задания выбрана «Согласовано», происходит переход на этап согласования внесенных изменений.

Требования к этапу согласования внесенных изменений в проект

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

Согласующий внесенные изменения для типов действия «дорожная карта», проект, непроектное мероприятие, государственная программа, подпрограмма является:

·  Руководитель департамента мониторинга Администрации губернатора Пермского края (Project.Stakeholder.OrganizationUnit.Head, если OrganizationUnitName = департамент мониторинга Администрации губернатора Пермского края)

Обязательным согласующим для типа действия непроектное мероприятие по привлечению федеральных финансовых средств (ФФС) является:

·  Определенный сотрудник департамента мониторинга Администрации Губернатора Пермского края (Николаева Е.В). (OrganizationUnitName = департамент мониторинга Администрации губернатора Пермского края.)

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

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

При назначении задачи должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.

Также ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета.

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

Далее происходит назначение задачи по согласованию запроса на изменение пользователю, указанному при перенаправлении задачи.

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

Этап согласования объекта управления длится до тех пор, пока количество согласовавших (со статусом «Согласовано») не будет равно количеству согласующих в списке.

Требования к этапу доработки внесенных изменений в проект

Если внесенные изменения в проект были отправлены согласующим на доработку, Исполнителю задачи по внесению изменений поступает задача «Доработайте внесенные изменения в проект». При назначении задачи должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.

Так же ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета.

Исполнитель задачи по доработке изменений должен иметь возможность перенаправить ее или выполнить самостоятельно.

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

Далее происходит назначение задачи по доработке внесённых изменений в проект пользователю, указанному при перенаправлении задачи.

Если форма исполнения задания выбрана «Выполнено», внесенные изменения в проект снова отправляется на круг согласования.

После завершения этапа согласования внесенных изменений в проект (согласовали все пользователи из списка согласующих со статусом «Согласовано») необходимо сохранить базовый план объекта управления (только по изменённым строкам), опубликовать и снять версию.

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

После публикации объекта управления процесс внесения изменений завершается.

Схема процесса внесения изменений приведена в Приложении Г.

 

.7 Общие требования к ИС УГП

В ходе сбора и систематизации требований были сформулированы требования, предъявляемые к ИС УГП.

Система предназначена для автоматизации деятельности по управлению государственными программами, а также проектами, «дорожными картами» и непроектными мероприятиями (далее - объектами управления).

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

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

В связи с тем, что разрабатываемая информационная система должна стать основным инструментом технологической поддержки управления проектной деятельностью ИОГВ и иметь единый источник данных о результатах достижения показателей государственных программ были сформулированы требования, касающиеся интеграции с ИАС ПК. Это позволит решить ряд организационных задач:

·  Сокращение трудозатрат, минимизация ошибок и повышение скорости выполнения процессов управления проектной деятельностью.

·        Обеспечение сопровождения полного жизненного цикла управления объектами управления.

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

·        Обеспечение результативности реализации объектов управления.

·        Соблюдение и сокращение сроков достижения результатов объектов управления.

·        Обеспечение эффективного использования временных, человеческих и финансовых ресурсов.

·        Прозрачность, обоснованность и своевременность принимаемых решений.

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

·        Вывод из действия ИАС УП, что в свою очередь позволит исключить из эксплуатации программное обеспечение зарубежного производства Microsoft Project и перейти к использованию технологий и платформ отечественного производства и/или свободно распространяемого программного обеспечения.

Требования к структуре и функционированию ИС УГП

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

Система должна функционировать на основе современных программно-технических решений и удовлетворять следующим общим требованиям:

·  Создание и развитие с использованием технологий и платформ отечественного производства и/или свободно распространяемого программного обеспечения.

·        Масштабируемость системы, как с помощью программных модулей, так и инфраструктурных компонентов.

·        Функционирование в архитектуре «клиент-сервер».

·        Совместимость и масштабируемость процедур информационного обмена между компонентами системы и с внешними информационными системами.

·        Интеграция модулей в рамках единого пользовательского интерфейса.

·        Обеспечение эффективной обработки и надежного хранения большого объема данных.

·        Обеспечение защиты от несанкционированного доступа.

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

Архитектура ИС УГП должна соответствовать трехуровневой клиент-серверной архитектуре и состоять из следующих уровней:

·  уровень хранения данных;

·        уровень приложений;

·        уровень клиента.

Общая программная архитектура ИС УГП приведена на рис. 2.7.

Рисунок 2.7 Общая программная архитектура ИС УГП

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

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

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

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

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

Требования к способам и средствам связи для информационного обмена между компонентами ИС УГП

Информационный обмен между компонентами ИС УГП должен обеспечиваться с помощью современных протоколов и форматов передачи данных (Web-сервисы, TCP/IP, XML-файлы). Между серверной частью ИС УГП и клиентскими приложениями информационный обмен должен осуществляться по протоколу HTTP. На транспортном уровне для взаимодействия компонентов ИС УГП должен использоваться стек протоколов TCP/IP.

Информационное взаимодействие между физическими серверами ИС УГП должно обеспечиваться посредством локальной сети типа Ethernet 100/1000, обеспечивающей передачу данных по протоколу TCP/IP.

 

.8 Функциональные требования

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

Предполагается несколько сценариев взаимодействия пользователя с системой:

·  Регистрация объекта управления в системе.

·        Разработка объекта управления, включающая:

o Заполнение основных сведений об объекте.

o   Формирование рабочей группы объекта

o   Формирование плана-графика.

o   Формирование перечня показателей.

o   Формирование плана финансирования.

o   Планирование рисков.

·  Согласование разработанного объекта.

·        Формирование отчетности о результатах достижения вех.

·        Согласование и утверждение фактических данных о достижении вех.

·        Внесение изменений в объект.

·        Согласование изменений.

·        Формирование регламентных отчетов.

·        Актуализация справочников.

·        Аудит изменений.

·        Администрирование процессов.

·        Администрирование базы данных.

·        Управление полномочиями и разрешениями.

Диаграмма прецедентов приведена на рис. 2.8.

Исходя из анализа сценариев взаимодействия ИС УГП и пользователя-участника проектной деятельности определен следующий состав модулей:

·  Единое веб-приложение.

·        Модуль организации рабочих областей объектов управления.

·        Личный кабинет пользователя.

·        Модуль паспортизации.

·        Модуль календарного планирования.

·        Модуль управления рисками.

·        Модуль отчетности и мониторинга.

·        Модуль хранения файлов документов.

·        Реестр пользователей.

·        Модуль исполнения процессов жизненного цикла проектов.

·        Технические и обеспечивающие модули:

Рисунок 2.7 Диаграмма прецедентов

o Интерфейс администрирования

o   Журналирование изменений данных ИС УГП

o   Нотификация пользователей

o   Интеграция с внешними системами

Перечисленные модули представлены в виде схемы функциональной структуры ИС УГП на рис. 2.8.

Рисунок 2.8 Общая функциональная структура ИС УГП

информационный проектный государственный управление

Требования к модулю реализации рабочего пространства объекта управления

Отображение данных о любом объекте управления ИС УГП должно быть реализовано в виде страницы рабочего пространства объекта управления, предоставляющего пользователям следующие возможности:

·  Отображение сводной информации по объекту управления.

·        Отображение сведений об объекте управления в зависимости от его типа.

·        Отображение плана-графика объекта управления.

·        Отображение данных о жизненном цикле объекта управления.

·        Отображение реестра рисков объекта управления.

·        Отображение связанных с объектом документов.

·        Отображение участников объекта управления и их ролей.

·        Отображение списка процессов изменений по проекту.

·        Механизм сравнения версий проектов.

·        Формирования печатной формы паспорта объекта управления.

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

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

Необходимо реализовать выбор режима просмотра объекта управления: только чтение или редактирование. При попытке открыть объект на редактирование должна осуществляться проверка на наличие прав на редактирование. Если у пользователя таких прав нет, должно выводиться сообщение об этом.

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

Требования к модулю паспортизации объектов управления

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

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

·  Номер и наименование объекта.

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

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

·        Сведения о Заказчике.

·        Данные об ответственном исполнителе объекта управления.

·        Сведения о руководителе и администраторе.

·        Соисполнители объекта управления - структурные подразделения, задействованные в реализации объекта управления.

·        Состав рабочей группы - участники объекта управления, задействованные в реализации, руководители и специалисты структурных подразделений организации.

·        Реестр рисков объекта управления.

·        План-график объекта управления в виде иерархического перечня работ, мероприятий и вех.

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

Отображение количества блоков на странице объекта управления должно зависеть от его типа.

Требования к паспортизации государственных программ и подпрограмм

Функциональные возможности страницы паспортизации объекта управления типа «Государственная программа» (далее - Программа) должны обеспечивать следующую дополнительную логику ввода и хранения данных, сгруппированных по блокам:

·  В рамках блока «Основные сведения»:

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

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

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

·        Раздел «Цели и Задачи» Программы должен содержать цели Программы и список ее задач, которые являются целями, входящих в Программу Подпрограмм. Пользователь должен иметь возможность указать в качестве цели Программы одно из значений справочника кодификатора целей и задач социально-экономического развития. Если в кодификаторе отсутствует значение, соответствующее цели программы, пользователю должна быть предоставлена возможность ручного ввода в поле «Цель Программы».

·        Дополнительный блок «Мероприятия» должен отображаться вместо блока «План» и содержать перечень основных мероприятий и мероприятий Подпрограмм, входящих в Программу. Мероприятия должны быть сгруппированы по основным мероприятиям. Основные мероприятия должны быть сгруппированы по Подпрограммам.

·        Блок «Показатели» должен содержать редактируемый перечень целевых показателей Программы и список для просмотра целевых показателей Подпрограмм, входящих в Программу. Целевые показатели должны содержать информацию о наименовании, единице измерения, периоде, плановом и фактическом значении. При формировании перечня целевых показателей Программы необходимо предоставить пользователю возможность связать целевой показатель со значением справочника целевых показателей ИС УГП. Целевые показатели подпрограмм должны отображаться с привязкой к мероприятиям и основным мероприятиям в группировке по Подпрограммам.

·        Блок «Финансирование» должен содержать плановые данные о финансировании Программы в разрезе источников финансирования и годов реализации объекта управления. Данные о финансировании программы, должны формироваться на основе суммирования данных о финансировании входящих в нее подпрограмм.

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

·  Пункты, вошедшие в паспорта программ.

·        Пункты, добавленные пользователем вручную при заполнении атрибутов программы или подпрограммы и требующие добавления в кодификатор.

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

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

·  В рамках блока «Основные сведения»:

o Необходимо обеспечить возможность указания наименования Государственной программы, к которой относится Подпрограмма. Наименование выбирается из перечня Государственных программ ИС УГП.

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

·  Дополнительный блок «Мероприятия» должен содержать перечень мероприятий и основных мероприятий подпрограммы.

·        Блок «Показатели» должен содержать перечень целевых показателей реализации Подпрограммы. При формировании перечня целевых показателей необходимо предоставить пользователю возможность выбрать показатель из значений справочника целевых показателей ИС УГП.

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

Требования к паспортизации объектов управления типа «Дорожная карта», «Проект» и «Непроектное мероприятие»

Функциональные возможности страницы паспортизации объектов управления типа «Дорожная карта», «Проект» и «Непроектное мероприятие» должны обеспечивать следующую дополнительную логику ввода и хранения данных, сгруппированных по блокам:

·  В рамках блока «Основные сведения»:

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

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

o   Необходимо обеспечить возможность ввода текстового описания правового обоснования.

o   Необходимо обеспечить возможность ввода текстового описания ожидаемого конечного результата.

o   Необходимо обеспечить возможность выбора перечня значений из справочника Стратегии СЭР.

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

o   Необходимо обеспечить возможность выбора перечня значений из справочника посланий Президента Российской Федерации.

o   Необходимо обеспечить возможность выбора Указа Президента РФ из справочника Указов Президента РФ,

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

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

·  Блок «Показатели» должен содержать перечень целевых показателей реализации объекта управления. Целевые показатели должны содержать информацию о наименовании, единице измерения, годе, плановом и фактическом значении. При формировании перечня целевых показателей необходимо предоставить пользователю возможность выбрать целевой показатель из значений справочника целевых показателей ИС УГП.

·        Блок «Финансирование» должен содержать плановые данные о финансировании в разрезе источников финансирования и годов реализации объекта управления.

Требования к паспортизации проектов типа «Непроектное мероприятие по привлечению федеральных финансовых средств»

Функциональные возможности страницы паспортизации проектов типа «Непроектное мероприятие по привлечению федеральных финансовых средств» (далее - ФФС) должен обеспечивать возможность просмотра и ввода следующей информации:

·  Блок «Сводная информация», содержащий сводку по проекту:

o Номер и наименование ФФС.

o   Сроки реализации - даты начала и окончания.

o   Наименование ИОГВ, ответственного за реализацию ФФС.

·  Блок «Основные сведения», содержащий сведения:

o Полное и краткое наименование ФФС и его номер.

o   Наименование ИОГВ, ответственного за реализацию ФФС.

o   Фамилия, имя и отчество сотрудника, заносящего данные в ИС УГП.

·  Блок «План», содержащий План-график в виде иерархической структуры мероприятий, работ и вех объекта управления, формируемый с использованием модуля календарного планирования.

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

·  Блок «Документы» должен содержать структуру файлов и папок, сопоставленных с объектом управления и формируемую с помощью модуля хранения файлов документов.

·  Блок «Процессы», содержащий сведения о текущем состоянии жизненного цикла, а также процессах выполняемых или завершенных по соответствующему проекту, формируемый с помощью модуля исполнения бизнес-процессов.

Требования к модулю календарного планирования

Для блока календарного планирования должен быть разработан веб-интерфейс для работы с иерархической структурой работ объекта управления.

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

·  Работу с отдельными элементами плана объекта.

·        Ввод и хранение атрибутов элементов плана:

o Наименование.

o   Идентификатор.

o   Статус.

o   Порядковый номер в структуре плана.

o   Плановые даты начала и окончания.

o   Фактические даты начала и окончания.

o   Процент завершения.

o   Перечень исполнителей из числа участников объекта управления.

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

o   Признак вехи объекта.

o   Уровень вехи.

o   Признак суммарного элемента плана.

o   Комментарий.

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

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

·        Создание структурной декомпозиции элементов плана. Определение связей между элементами плана типа родитель-потомок.

·        Определение последовательности выполнения элементов плана, создание связей между элементами плана типа предшественник-последователь.

·        Сохранение базового плана объекта управления.

·        Отображение диаграммы Ганта, и анализ выполнения плана на основе заданных базовых значений.

·        Формирование плана по шаблону, включающего в себя структурированный перечень работ.

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

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

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

Также необходимо обеспечить отображение состояний вех:

·  Просрочена - недостигнутая веха.

·        В процессе утверждения - по вехе запущен процесс отчетности по исполнению.

·        Достигнута - утверждение вехи в процессе отчетности по исполнению завершено и данные актуализированы в проекте.

·        Веха будущего периода.

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

Требования к модулю управления рисками

Модуль должен обеспечивать возможность создавать и отслеживать реестры рисков в рамках блока «Риски» страницы паспортизации и рабочей области объекта управления.

Реестр рисков должен быть организован в виде списка и обеспечивать следующие функции:

·  Поиск, фильтрация и сортировка рисков по отображаемым атрибутам

·        Регистрация нового риска (создание карточки риска).

·        Просмотр карточки риска и изменение атрибутов риска.

Модуль должен обеспечивать возможность просмотра и ввода следующих данных о рисках:

·  Наименование риска и его описание.

·        Категория риска.

·        Ответственный за снятие/минимизацию риска, выбираемый из списка рабочей группы объекта управления.

·        Оценка в процентах вероятности возникновения и влияния риска.

·        Текстовое описание действий по снятию риска.

·        Прикрепление файлов документов к карточке риска.

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

·        Признак актуальности риска.

·        Признак осуществления риска.

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

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

Требования к модулю хранения файлов документов

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

Модуль должен обеспечивать:

·  Загрузку файлов в Систему через соответствующий визуальный интерфейс в браузере.

·        Централизованное хранение файлов, загружаемых в Систему.

·        Сопоставление загруженных файлов с отдельными элементами ИС УГП

·        Отображение файлов в настраиваемой структуре папок в следующих разделах ИС УГП:

o Центр документов, отображающий файлы, не сопоставленные с конкретными элементами ИС УГП

o   Блок «Документы» паспорта объекта управления, отображающий файлы, сопоставленные с элементами соответствующего объекта управления.

·  Поиск и сортировка файлов в списках по отображаемым атрибутам.

·        Выгрузка файлов по запросу пользователя.

Требования к реализации личного кабинета пользователя

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

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

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

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

Перечень блоков Личного кабинета:

o Мои объекты.

o   Мои вехи.

o   Вехи на контроле.

o   Вехи моих объектов.

o   Мои задачи.

o   Мои риски.

o   Замещение.

o   Оперативное планирование.

·  Блок «Мои объекты», отображающий перечень доступных пользователю объектов управления, участником которых он является, с указанием наименования и роли, а также возможностью открыть страницу паспорта объекта управления.

·        Блок «Мои вехи», отображающий перечень вех, на которые пользователь назначен исполнителем, с указанием сроков выполнения и возможностью открыть карточки соответствующих элементов.

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

o Наименование вехи.

o   Срок исполнения.

o   Комментарий.

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

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

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

o Наименование вехи.

o   Срок исполнения.

o   Фактическая дата исполнения.

o   Фамилия, имя и отчество ответственного.

o   Комментарий.

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

Блок должен отображаться только для пользователей, определенных руководителями структурных единиц (ФЦБ, ИОГВ, ФО/ФП) или ответственными за проектное управление в них. Если пользователь одновременно является руководителем двух структурных единиц разных уровней необходимо отображать информацию по организации более высокого уровня. Например, если пользователь одновременно руководитель ФЦБ и руководитель ИОГВ должны отображаться вехи проектов, ответственные исполнители которых включены в это ФЦБ.

·  Блок «Вехи моих объектов» - блок, содержащий перечень вех объектов управления в которых авторизованный пользователь является Руководителем или Администратором.

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

o Наименование вехи.

o   Срок исполнения.

o   Фактическая дата исполнения.

o   Фамилия, имя и отчество ответственного.

o   Комментарий.

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

·  Блок «Мои задачи», в котором приводится перечень поступивших задач процессов с возможностью открыть форму выбранной задачи. Список поступивших пользователю задач должен содержать следующую информацию:

o Наименование задачи.

o   Автор задачи.

o   Дата поступления задачи.

o   Срок исполнения задачи.

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

·  Блок «Мои риски», содержащий перечень назначенных активных рисков с возможностью открыть карточки соответствующих элементов. Список рисков должен содержать следующую информацию:

o Наименование риска.

o   Содержание риска.

o   Дата наступления риска.

Риски в списке должны быть отсортированы по дате наступления от старых к новым.

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

·        Блок «Оперативное планирование» - блок отображения информация о необходимости и сроках формировании документов оперативного планирования с указанием наименования периода, типа документа (Отчет за период, План на период), дат начала и окончания периода, даты закрытия периода, результата формирования отчета.

Каждый блок должен отображать весь список записей списков и иметь вертикальную полосу прокрутки справа.

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

Требования к модулю исполнения процессов жизненного цикла объектов управления

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

На протяжении всего жизненного цикла объект управления должен проходить ряд последовательных этапов от инициации до полного завершения:

·  Инициация.

·        Планирование.

·        Исполнение.

·        Завершение.

На этапе инициации должны определяться основные параметры объекта управления: наименование, тип объекта управления и его руководитель.

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

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

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

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

Модуль должен обеспечивать исполнение бизнес-процессов, соответствующих этапам жизненного цикла объектов управления:

·  Разработка.

·        Внесение изменений.

·        Отчетность по исполнению

В целях обеспечения преемственности и сохранения существующего опыта в сфере проектного управления должны быть использованы существующие в ИАС УП технологические решения по автоматизации исполнения процессов жизненного цикла объектов управления.

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

·  Процесс разработки объекта управления.

·        Процесс отчетности по исполнению.

·        Процесс изменения объекта управления.

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

Исполнитель задачи процесса должен иметь возможность перенаправления назначенной ему задачи другому исполнителю из списка пользователей ИС УГП.

Требования к модулю отчетности и мониторинга

Модуль должен обеспечивать формирование аналитической и регламентной отчетности на основе внесенных данных.

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

Периодами оперативного планирования должны являться:

·  Для проектов и непроектных мероприятий (кроме непроектных мероприятий по привлечению федеральных финансовых средств): календарная неделя, месяц, квартал, год.

·        Для «дорожных карт»: месяц, квартал, год.

·        Для подпрограмм государственных программ: квартал, полугодие, год.

По каждому периоду Руководитель или Администратор объекта управления должен иметь возможность сформировать «План на период» и «Отчет за период» нажатием кнопки «Сформировать».

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

Требования к модулю перенаправления задач процессов другим пользователям на период отсутствия исполнителя

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

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

Замещение может находиться в одном из трех состояний:

·  Запланировано.

·        Действующее.

·        Завершено.

Созданное замещение считается запланированным, если дата начала замещения еще не наступила. В 00:00:00 даты начала замещение переходит в статус «Действующее». При создании замещения, дата начала которого равна текущей дате, замещение переходит в статус «Действующее» сразу после его сохранения. Действие замещения заканчивается в 23:59:59 даты окончания замещения или в момент принудительной остановки замещения. По окончанию действия завершения оно переходит в статус «Завершенное». Статус присваивается замещению автоматически.

Любой пользователь системы должен иметь возможность создать «Замещение» и назначить заместителя только на себя, а также редактировать замещение только в статусе «Запланированное». Также пользователь может остановить «Действующее» замещение, если он является замещаемым.

·  Пользователь, имеющий разрешения для создания замещений для других пользователей, может: Создать замещение и назначить для любого пользователя - любого заместителя, из пользователей ИС УГП.

·        Редактировать любое замещение в статусе «Запланированное».

·        Редактировать атрибут «Основание» любого замещения в статусе «Действующее» или «Завершённое».

·        Остановить любое «Действующее» замещение.

Создание замещения должно происходить при нажатии на кнопку «Оформить замещение» в разделе «Замещение» Личного кабинета.

При нажатии на кнопку «Оформить замещение» должна открываться форма создания замещения.

Поле «Замещаемый» должно заполняться автоматически при создании замещения пользователем, не имеющим специальных разрешений. Пользователь, имеющий разрешения для создания замещений для других пользователей, должен иметь возможность выбрать значение из списка активных пользователей ИС УГП.

·  Поле «Заместитель» должно выбираться из списка активных пользователей ИС УГП.

·        Поле «Дата начала» должно заполняться пользователем вручную путем ввода значения в поле, либо путем выбора с помощью виджета «Календарь»;

·        Поле «Дата окончания» должно заполняться пользователем вручную путем ввода значения в поле, либо путем выбора с помощью виджета «Календарь»;

·        Поле «Основание» должно заполняться пользователем вручную путем ввода текста.

После заполнения у пользователя появляется возможность сохранить замещение, нажав кнопку «Сохранить». У пользователя должна быть возможность закрыть форму без сохранения.

Созданное замещение должно быть доступно создавшему его пользователю или пользователю, обладающему специальными разрешениями, для редактирования или удаления до наступления даты начала замещения. После наступления даты начала замещения для редактирования доступно только поле «Основание».

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

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

Требования к техническим и обеспечивающим модулям

К техническим и обеспечивающим модулям относятся:

·  Модуль ведения реестра участников проектной деятельности.

·        Модуль администрирования.

·        Модуль журналирования изменений данных ИС УГП.

·        Модуль нотификации пользователей ИС УГП.

Требования к модулю ведения реестра участников проектной деятельности

Модуль предназначен для создания, хранения и редактирования реестра участников проектной деятельности ИС УГП и должен обеспечивать возможность ввода и просмотра следующей информации:

·  Сопоставление с пользователем ИС УГП, содержащее следующую информацию, не подлежащую изменению:

o Фамилия, имя и отчество пользователя.

o   Логин пользователя.

·  Отметка активного статуса участника проектной деятельности в Системе.

·        Адрес электронной почты.

·        Место работы и должность.

·        Группа безопасности в системе в соответствии с заданным уровнем полномочий.

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

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

Требования к модулю администрирования

Модуль должен обеспечивать выполнение следующих функций:

·        Разграничение прав доступа к данным и функциям ИС УГП.

·        Ведение и актуализация справочников и классификаторов.

·        Просмотр журналов изменений.

·        Просмотр, отслеживание, прекращение запущенных пользователями процессов.

Функции администрирования ИС УГП должны быть доступны только участникам проектной деятельности, входящим в группу полномочий администраторов ИС УГП.

Требования к модулю журналирования изменений данных ИС УГП

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

Модуль должен обеспечивать выполнение следующих функций:

·  Фиксация факта внесения изменений в данные ИС УГП.

·        Сохранение данных о наименования измененного объекта, пользователя, вносившего изменения, даты и времени внесения изменений.

·        Возможность просмотра журналов изменений в виде списка.

·        Поиск и сортировка данных по отображаемым списке атрибутам.

Требования к модулю нотификации пользователей

Модуль должен обеспечивать своевременное извещение пользователей о необходимости выполнения действий в системе с использованием электронной почты.

Модуль должен обеспечивать выполнение следующих функций:

·  Извещение пользователей о поступлении задачи процесса по электронной почте в утвержденной форме.

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

o Исполнители должны получать уведомления о вехах, находящихся на исполнении в ближайшие дни.

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

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

 

.9 Требования к структуре базы данных

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

Для моделирования структуры данных использовалась платформа Flexberry.

Ниже приведен перечень таблиц базы данных. Подробное описание и атрибутный состав каждой таблицы приведено в Приложении Б.

·  Project - таблица, хранящая данные об объекте управления.

·        ProjectGoal - таблица, содержащая сведения о целях объекта управления. Связана с Project отношением 1:N.

·        ProjectObjective - таблица для хранения данных о задачах объекта управления. Связана с Project отношением 1:N.

·        ProjectStakeholder - для хранения данных о заинтересованных сторонах объекта управления. Связана с Project отношением 1:N.

·        ProjectResources - таблица, предназначенный для хранения данных об участниках рабочей группы объекта управления. Связана с Project отношением 1:N.

·        ProjectFinance - таблица для хранения сведений о финансировании объекта управления. Связана с Project отношением 1:N.

·        ProjectKPI - для хранения данных о показателях достижения целей и задач объекта управления. Связана с Project отношением 1:N.

·        Task - таблица, содержащая сведения о задаче календарного плана объекта управления. Этот таблица является дочерней по отношению к «Project».

·        Assignment - таблица для хранения данных о назначениях по каждому элементу календарного плана. Каждой записи сопоставлена запись «Task».

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

·        ProgressApproval - таблица, предназначенная для хранения данных о результатах согласования каждого отчета об исполнении. Ссылается на ProgressReport.

·        TaskLink - таблица для хранения данных о связях между задачами календарного плана.

·        ProjectRisk - таблица для хранения сведений о рисках объекта управления. Ссылается на Project.

·        TaskRisk - таблица для хранения данных о связях риска объекта управления с задачей календарного плана и степени влияния на нее. Ссылается на ProjectRisk и Task.

·        User - класс для хранения учетных данных о пользователе: его логин, фамилия, имя, отчество.

·        Person - класс для хранения сведений об участниках проектной деятельности. Ссылается на User.

·        Resource - сведения о ресурсах, используемых в проектной деятельности. Ссылается на Person.

·        OrganizationUnit, содержащий данные об органах власти, задействованных в проектной деятельности.

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

·        ProjectType - таблица, содержащая перечень типов объектов управления. Справочник.

·        TaskType - таблица-справочник с перечнем типов задач календарного плана.

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

·        ProjectStage - таблица-справочник с перечнем стадий, которая присваивается объекту управления в ходе процессов жизненного цикла.

·        КодификаторЦелейИЗадач - иерархический справочник, содержащий структуру целей и задач социально-экономического развития Пермского края.

·        СтратегияСЭР - иерархический справочник, содержащий структуру Стратегии социально-экономического развития Пермского края.

·        УказыПрезидентаРФ -справочник, содержащий перечень указов Президента РФ.

·        ПосланиеПрезидента - иерархический справочник, содержащий структуру посланий президента РФ.

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

 

Выводы по второй главе

В ходе анализа бизнес-процессов управления проектами, действующими в ИАС УП, были разработаны их модели AS IS, которые были проанализированы. Были сформулированы рекомендации по их модернизации. На основе проведенного анализа были разработаны модели процессов TO BE с учетом рекомендаций.

Разработаны требования к реализации процесса разработки объекта управления, процессу внесения изменений в объект, процессу отчетности об исполнении с учетом исправления «узких мест», обнаруженных на этапе анализа.

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

На основе этих требований разработаны требования к структуре базы данных и описаны с использованием диаграмм классов.

3. Взаимодействие ИС УГП с ИАС ПК

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

Для реализации этого требования необходимо определить состав передаваемых данных и разработать регламент информационного взаимодействия ИС УГП и ИАС ПК.

3.1 Описание Информационной аналитической системы Пермского края

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

Информация, размещаемая в ИАС ПК, по степени ее конфиденциальности является открытой.

В состав ИАС ПК входят следующие системы:

·  Система «Управление Централизованным Хранилищем Данных»;

·        Система «Оперативный мониторинг социально-экономического положения Пермского края»;

·        Система «Моделирование и прогнозирование показателей социально-экономического развития»;

·        Система «Управление деятельностью органами исполнительной государственной власти Пермского края на основе целевых показателей»;

·        Система «Мобильный офис губернатора края»;

·        Система «Региональный сегмент ГАС «Управление»;

·        Система «Специализированный информационный ресурс ограниченного доступа на базе Закрытого сегмента ИАС Пермского края».

В ИАС ПК ведется перечень подпрограмм и мероприятий и каждой подпрограмме соответствует перечень целевых показателей.

Сотрудники ИОГВ, являющиеся ответственными за достижение целевых показателей социально-экономического развития периодически формируют отчет о результатах и размещают его в ИАС ПК. Каждый отчет должен проходить процедуру согласования и утверждения заинтересованными сторонами.

3.2     Интеграционная платформа Highway SB

В качестве инструмента взаимодействия проектируемой ИС УГП с внешними информационными системами предполагается использование единой региональной интеграционной платформы Highway SB, являющейся средством интеграции ведомственных информационных систем органов власти Пермского края.

Интеграционная платформа Highway SB (далее - сервисная шина) организована по принципу корпоративной сервисной шины (ESB) и разработана на базе отечественного программного обеспечения.

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

Интеграционная платформа Highway SB поддерживает следующие возможности [20]:

·  Настройка маршрутов взаимодействия в пользовательском интерфейсе, без программирования.

·        Гарантированная доставка сообщений как по запросу, так и автоматически на сервис получателя.

·        Организация очереди сообщений.

·        Обработка событий.

·        Работа с пакетами сообщений.

Схема взаимодействия проектируемой системы и внешних информационных систем приведена на рис. 3.1.

Рисунок 3.1 Схема интеграции ИС УГП с внешними ИС

3.3   Состав передаваемых данных

Информационный обмен между ИС УГП и ИАС ПК должен происходить посредством отсылки и приема электронным сервисом участника информационного обмена асинхронных сообщений в Региональную сервисную шину.

Для реализации этих требований был определен состав передаваемых данных.

В рамках информационного взаимодействия из ИАС ПК в ИС УГП должны передаваться следующие данные:

·  Данные о пользователях.

·        Справочник органов власти.

·        Кодификатор целей и задач.

·        Справочник целевых показателей социально-экономического развития.

В рамках информационного взаимодействия из ИС УГП в ИАС ПК должны передаваться следующие данные:

·  Данные об объектах управления.

·        Календарные планы объектов управления.

·        Цели и задачи объектов управления.

·        Показатели объектов управления.

Детальный атрибутный состав передаваемых данных приведен в Приложении Е.

 

Выводы по четвертой главе

В соответствии с требованиями к интеграции ИС УГП с ИАС ПК разработан регламент информационного обмена данными между этими системами.

В качестве инструмента взаимодействия проектируемой ИС УГП с внешними информационными системами предполагается использование единой региональной интеграционной платформы Highway SB, являющейся средством интеграции ведомственных информационных систем органов власти Пермского края.

ЗАКЛЮЧЕНИЕ

В ходе работы над диссертацией поставленные задачи были решены и были достигнуты перечисленные ниже результаты.

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

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

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

Были собраны и формализованы общие требования к Системе управления программами. На основе которых были разработаны функциональные требования к модулям ИС УГП.

С использованием диаграмм классов было проведено проектирование базы данных ИС УГП. Результатами решения задачи являются модели данных и описание атрибутного состава классов.

Для обеспечения интеграции проектируемой системы и внешних информационных систем были сформулированы требования для реализации информационного обмена данными между системой управления государственными программами и ИАС ПК. на основе сформулированных требований разработан «Регламент информационного обмена данными между Системой управления государственными программами и ИАС ПК».

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

Практическая значимость работы заключается в следующем:

·  Результаты использованы разработке подсистемы управления государственными в составе ИАС ПК для внедрения в Администрации губернатора Пермского края.

·        Интеграция информационных систем, предназначенных для автоматизации процесса управления государственными программами.

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

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

·        Вывод из эксплуатации существующей ИАС УП на платформе MS Project.

СЛОВАРЬ ТЕРМИНОВ И СОКРАЩЕНИЙ

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

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

Документы стратегического планирования - документы, указанные в Законе Пермского края от 2 апреля 2010 г. №598-ПК «О стратегическом планировании в Пермском крае».

ИАС ПК - Информационно-аналитическая система Пермского края. Используется для обеспечения автоматизации стратегического планирования и управления социально-экономическим развитием.

ИАС УП - Информационно-аналитическая система управления проектами на платформе Microsoft Project Server.

ИОГВ - исполнительный орган государственной власти.

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

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

Объект управления - государственная программа, подпрограмма государственной программы, проект, «дорожная карта», непроектное мероприятие.

Основное мероприятие - комплекс мероприятий, направленных на решение конкретной задачи в рамках подпрограммы

Подпрограмма - комплекс основных мероприятий (ведомственных целевых программ) и мероприятий, направленных на решение конкретных задач в рамках государственной программы.

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

ФЦБ - функционально-целевой блок.

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Благодатский Г.А. Программно-инструментальные средства повышения эффективности внутренних бизнес-процессов предприятий: автореферат диссертации на соискание ученой степени кандидата технических наук: 05.13.01 / Благодатский Григорий Александрович. - Ижевск, 2012. - 25 с.

2.      Боков Н.А. Системный анализ и моделирование бизнес-процессов при разработке и внедрении информационных систем телекоммуникационных компаний: автореферат диссертации на соискание ученой степени кандидата технических наук: 05.13.01/ Боков Николай Александрович. М., 2009. 28 с.

.        Вендров А.М. Методы и средства моделирования бизнес-процессов (обзор) [Электронный ресурс] / А.М. Вендров // Jet Info Информационный бюллетень №10 (137)/2004.

.        Гелёва А.А. Проектное управление в органах государственной власти [Электронный ресурс] / А.А. Гелёва // Научное сообщество студентов XXI столетия. Экономические науки: сб. ст. по мат. XLVII междунар. студ. науч.-практ. конф. №10(47)

.        Главное преимущество BPMN [Электронный ресурс] // Открытые системы. СУБД. 2012. №08

.        ГОСТ Р ИСО 9000-2008. ИС УГП менеджмента качества. Основные положения и словарь. - М.: Стандартинформ, 2008. - 70 с.

.        Дементьев В.В. Проектное управление в системе стратегического планирования [Электронный ресурс] / В.В. Дементьев // Бюджетная политика. 2012. №9

.        Официальный сайт платформы Bonita BPM Platform

.        Панов А.В., Разыграев С.В. Оптимизация анализа бизнес-процессов в технике и технологиях [Электронный ресурс] / А.В. Панов, С.В. Разыграев // Информационные технологии в проектировании и производстве. 2010. №1. С. 47-52

.        Паспорт лучшей практики №IT-1 Практика применения информационной системы в управлении Государственными программами в Департаменте информационных технологий города Москвы [Электронный ресурс]

.        ПМ Форсайт. Эффективное управление объекта управлениями [Электронный ресурс]

.        Перегудов Ф.И., Тарасенко, Ф.П. Введение в системный анализ. Учеб. пособие для вузов. - М.: Высшая школа, 1989. - 367 с.

.        Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. - М., РИА «Стандарты и качество», 2004 - 408 с.

.        Севастьянов Р.С. Экономические информационные системы органов федерального казначейства: анализ и моделирование бизнес-процессов: автореферат диссертации на соискание ученой степени кандидата экономических наук: 08.00.13/ Севастьянов Роман Сергеевич. - Ростов-на-Дону, 2011. - 27с.

.        Селиверстова П.О., Точилкина Т.Е. Обзор лидеров BPMS [Электронный ресурс]/ П.О. Селиверстова, Е.Е. Точилкина // Экономика и менеджмент инновационных технологий. 2014. №12

.        Тлисов А.Б., Киселева Н.Н. Внедрение проектного управления в деятельность органов власти региона как механизм повышения его инвестиционной привлекательности [Электронный ресурс] / А.Б. Тлисов, Н.Н. Киселева // Управленческое консультирование. 2016 г. №12, с. 49-54.

.        Указ губернатора Пермского края от 20 ноября 2014 года №196 «Об утверждении положения по управлению «дорожными картами», проектами, программами и непроектными мероприятиями».

.        Указ губернатора Пермского края от 27 сентября 2010 года №70 «Об администрации губернатора пермского края».

.        Универсальный сервис интеграции систем Highway SB [Электронный ресурс]

.        Управление проектами в органах власти [Электронный ресурс]

.        Федоров, И.Г. Моделирование бизнес процессов в нотации BPMN2.0: Монография, М., 2013г. МЭСИ. - 255 с.

.        Хубаев Г.Н., Щербаков, С.М., Рванцов, Ю.А. Инструментарий интеграции визуального и имитационного моделирования // Вестник ДГТУ. 2011 г. Т II, №7 (58), с. 1035-1045.

.        Чеботарев В.Г., Бородина, Е.Г., Григорьева, Д.М. Особенности применения субъектно-ориентированного моделирования бизнес-процессов // Бизнес-информатика. 2010 г, №2 (12), с. 54-59.

.        Червенчук И.В. Использование средств объектно-ориентированного анализа для описания бизнес-процессов и разработки информационных систем [Электронный ресурс] / И.В. Червенчук // Профессиональное образование в развитии региона и общества: традиции, творчество, технологии. Материалы Международной научно-практической конференций, посвященной 35-летию ФГБОУ ВПО «ОГИС». Омский государственный институт сервиса; под общей редакцией Д.П. Маевского. Омск, ОГИС, 2012. С. 63-65

.        ELMA BPM. Управление бизнес-процессами [Электронный ресурс]

26.    JBPM - часть 1 - process management engine от JBOSS [Электронный ресурс]

ПРИЛОЖЕНИЕ А

 

Описание типовых функций проектных ролей участников проектной деятельности органов власти и Администрации губернатора Пермского края

МВК по СЭР ПК исполняет следующие функции:

·  Осуществляет рассмотрение и утверждение предложений об инициации объекта управления.

·        Осуществляет рассмотрение рисков и проблем, эскалируемых на МВК по СЭР ПК.

·        Проводит оценку результативности и эффективности объекта управления.

·        Принимает решение о завершении и приостановлении объекта управления.

В перечень функций Проектного офиса входят:

·  Внедрение и развитие методологии проектного управления в исполнительных органах государственной власти Пермского края, структурных подразделениях администрации губернатора Пермского края, аппарата Правительства Пермского края;

·        Разработка и внедрение нормативных правовых актов и методической документации по проектному управлению;

·        Организация и мониторинг планирования, реализации и управления изменениями объекта управления.

·        Внедрение, поддержка и развитие ИАС УП (роль функционального администратора:

·        Наполнение справочников, классификаторов и словарей и иные содержательные изменения ИАС УП.

·        Администрирование пользователей и прав доступа.

·        Введение в действие и поддержка документов по использованию ИАС УП участниками проектной деятельности.

·        Развитие отдельных модулей ИАС УП.

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

·        Координация обучения участников проектной деятельности проектному управлению и работе в ИАС УП.

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

Заказчик объекта управления выполняет следующие функции:

·  Утверждает проектную документацию объекта управления.

·        Принимает решения по запросам на изменение объекта управления по целям, срокам реализации, бюджету, результатам.

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

·        Принимает результаты работ, включая промежуточные результаты.

Руководитель функционально-целевого/функционального блока выполняет функции:

·  Согласует паспорт и план-график объекта управления.

·        Согласует выполнение вех и прогнозов выполнения вех будущих периодов.

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

·        Осуществляет разрешение рисков и проблем, выходящих за рамки компетенции Руководителя и руководителя ИОГВ.

·        Согласует значений ключевых показателей эффективности для участников объекта управления.

В перечень функций Ответственного за проектное управление функционально-целевого/функционального блока входят следующие:

·  Консультирование специалистов ИОГВ функционально-целевого/функционального блока по вопросам разработки и реализации объекта управления, работе в ИАС УП.

·        Экспертиза планов-графиков и паспортов объекта управления ИОГВ функционально-целевого/функционального блока.

·        Обеспечение актуальности реестра объектов управления функционально-целевого/функционального блока;

·        Обеспечение актуальности портфелей объектов управления функционально-целевого/функционального блока.

·        Экспертиза отчетности по объектам управления функционально-целевого/функционального блока.

·        Контроль формирования планов на период и отчетов за период по объектам управления функционально-целевого/функционального блока в ИАС УП.

·        Контроль и согласование изменений в паспорт и план-график объектов управления функционально-целевого/функционального блока.

·        Обеспечение актуальности учетных записей пользователей функционально-целевого/функционального блока в ИАС УП.

·        Эскалация рисков и проблем объекта управления на уровень руководителя функционально-целевого/функционального блока при отсутствии единой позиции с руководством объекта управления.

·        Иные функции в сфере проектного управления по решению руководителя функционально-целевого/функционального блока.

Руководитель ИОГВ в рамках деятельности по проектному управлению выполняет следующие функции:

·  Осуществляет согласование паспорта и плана-графика объекта управления.

·        Осуществляет контроль реализации объектов управления ИОГВ.

·        Согласует выполнение вех и прогнозов выполнения вех будущих периодов.

·        Назначает Руководителя и Администратора объекта управления.

·        Назначает должностных лиц ИОГВ для участия в объекте управления других ИОГВ в качестве исполнителей.

Ответственный за проектное управление в ИОГВ выполняет следующие функции:

·  Консультирует специалистов ИОГВ по вопросам разработки и реализации объекта управления, работе в ИАС УП.

·        Проводит проверку планов-графиков и паспортов объектов управления ИОГВ.

·        Обеспечивает актуальность реестра объектов управления ИОГВ.

·        Обеспечивает актуальность портфелей объектов управления ИОГВ.

·        Осуществляет контроль отчетности по объектам управления ИОГВ.

·        Осуществляет контроль реализации оперативного планирования (формирования планов и отчетов) по объектам управления ИОГВ в ИАС УП.

·        Осуществляет контроль и согласование изменений в паспорт и план-график объектов управления ИОГВ.

·        Обеспечивает актуальность учетных записей пользователей ИОГВ функционально-целевого/функционального блока направления в ИАС УП.

·        Осуществляет эскалацию рисков и проблем объекта управления на уровень руководителя ИОГВ при отсутствии единой позиции с руководителем объекта управления.

·        Выполняет иные функции в сфере проектного управления по решению руководителя ИОГВ.

Руководитель объекта управления:

·  Осуществляет руководство процессами планирования, исполнения, управления изменениями, контроля и завершения объекта управления.

·        Добивается достижение целей и задач объекта управления.

·        Осуществляет оперативное управление объекта управления.

·        Организует работу по оперативному планированию и реализации объекта управления.

·        Согласует заявки на изменение объекта управления.

·        Осуществляет контроль хода реализации " объекта управления.

·        Организует и координирует работу команды (рабочей группы, проектного офиса) объекта управления.

·        Осуществляет распределение задач (работ) и вех между исполнителями.

·        Утверждает отчеты по объекту управления.

·        Организует подготовку и согласование запросов на изменение проектной документации.

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

Руководитель блока работ - должностное лицо ИОГВ, ответственное за реализацию задач (работ) определенного блока работ - выполняет следующие функции:

·  Обеспечивает достижение целей и результатов по блоку работ.

·        Организует работу исполнителей по блоку работ.

·        Осуществляет согласование отчетов исполнителей по блоку работ.

·        Осуществляет подготовку предложений по установлению значений ключевых показателей эффективности для исполнителей блока работ " объекта управления.

В функции Администратора объекта управления входят:

·  Подготовка первой версии проектной документации и согласование проектной документации с заинтересованными лицами.

·        Организация сбора отчетности, подготовка отчетности по объекту управления.

·        Выполнение процесса оперативного планирования в ИАС УП.

·        Корректировка проектной документации по утвержденным запросам на изменение.

·        Подготовка и протоколирование совещаний по объекта управления.

·        Ведение архива объекта управления в ИАС УП.

·        Помощь Руководителю в решении отдельных задач.

Исполнитель объекта управления осуществляет выполнение следующих функций:

·  Выполнение отдельных задач (работ) и вех объекта управления.

·        Формирование отчетности по задачам (работам) и вехам, в том числе прогноз исполнения вех.

·        Выполнение запросов на изменение по задачам (работам) и вехам.

·        Эскалация рисков и проблем на уровень Руководителя блока работ, Руководителя объекта управления.

ПРИЛОЖЕНИЕ Б

 

Описание состава атрибутов модели данных ИС УГП управления государственными программами

Модуль паспортизации объекта управления, блок «Основные сведения»

Таблица «Project» - предназначена для хранения данных об объекте управления.

Таблица Б.1

Таблица «Project»

Атрибут		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Type	Ссылка на справочник ProjectType	GUID	Справочное поле	Указывает тип о объекта управления От типа корпоративного объекта управления зависит шаблон объекта управления, включающий календарный план, стадии жизненного цикла объекта управления, структуру папок и файлов.		-
Number		tString100	Текстовое поле	Номер, который автоматически присваивается проекту при его создании.		-
Name		tString255		Название объекта управления	+	+
Description		tString255		Краткое описание объекта управления	-	+
isTemplate		bool=false		Определение объекта как шаблона. Принимает значение «true», если выполнена операция сохранения объекта в виде шаблона.		-
InitiationDate		nDate	Календарь	Дата принятия решения о создании объекта управления. При создании объекта управления по умолчанию устанавливается текущая дата, которую можно изменить в ходе редактирования.	-	+
StartDate		nDate		Запланированная дата начала объекта управления. При создании объекта управления по умолчанию устанавливается текущая дата, которую можно изменить.	+	+
FinishDate		nDate		Запланированная дата завершения объекта управления При создании объекта управления пустое.	+	+
ProjectVersionType		tString100	Поле со списком	Указание версии объекта управления: · Опубликованная. · Рабочая. · Архивная		-
Priority		int		Указывает важность и значимость объекта управления	-	+
Status	Ссылка на справочник ProjectStatus	GUID	Справочное поле	Статус объекта управления. Принимает значения в ходе жизненного цикла объекта управления.		Только Администратору системы
Customer	Ссылка на справочник OrganizationUnit	GUID	Справочное поле	Выбор Заказчика объекта управления	-	+
Doer	Ссылка на справочник OrganizationUnit	GUID	Справочное поле	Выбор органа власти, ответственного за достижение результатов объекта управления	+	+
ФЦБ	Ссылка на справочник OrganizationUnit	GUID	Справочное поле	Выбор функционального блока, ответственного за достижение результатов объекта управления	+	+
Manager	Ссылка на справочник Person	GUID	Справочное поле	Выбор руководителя объекта управления из справочника участников проектной деятельности	+	+
Администратор	Ссылка на справочник Person	GUID	Справочное поле	Выбор администратора объекта управления из справочника участников проектной деятельности	+	+
Краткое Наименование		tString100	Текстовое поле для ввода вручную		-	+
Основание		tStringMax	Текстовое поле для ввода вручную	Поле для ввода основания реализации объекта управления	-	+
Ожидаемый Результат		tStringMax	Текстовое поле для ввода вручную	+	+
Оценка Достижения Целей И Задач		tStringMax	Текстовое поле для ввода вручную	Поле для заполнения результатов реализации объекта управления на этапе завершения	-	+
Оценка Результатов Участников		tStringMax	Текстовое поле для ввода вручную	Поле для заполнения результатов реализации объекта управления на этапе завершения	-	+
Оценка Решения Проблем		tStringMax	Текстовое поле для ввода вручную	Поле для заполнения результатов реализации объекта управления на этапе завершения	-	+
Инструменты Реализации		tStringMax	Текстовое поле для ввода вручную		-	+

Таблица «ProjectGoal» - дочерняя таблица к «Project». Содержит данные о целях объекта управления.

Таблица Б.2

Таблица «ProjectGoal»

Атрибут		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Project	Ссылка на родительскую таблицу	GUID			+	-
Description			Текстовое поле	Поле для ввода вручную цели объекта, если в справочнике Кодификатора целей и задач СЭР нет соответствующего значения	+	+
Цель	Ссылка на справочник ПунктЦиЗСЭР	GUID	Справочное поле		+	+

Таблица «ProjectObjective» - дочерняя таблица к «Project». Содержит данные о задачах объекта управления.

Таблица Б.3

Таблица «ProjectObjective»

Атрибут		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Project	Ссылка на родительскую таблицу	GUID			+	-
Description			Текстовое поле	Поле для ввода вручную цели объекта, если в справочнике Кодиификатора целей и задач СЭР нет соответствующего значения	+	+
Задача	Ссылка на справочник ПунктЦиЗСЭР	GUID	Справочное поле		+	+

Таблица «Уровень Контроля Проекта» - дочерняя таблица к «Project». Содержит данные об уровне контроля объекта управления.

Таблица Б.4

Таблица «Уровень Контроля Проекта»

Атрибут		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Project	Ссылка на родительскую таблицу	GUID			+	-
Уровень Контроля	Ссылка на справочник Уровень Контроля	GUID	Справочное поле		+	+

Таблица «Послание Президента Проекта» - дочерняя таблица к «Project». Содержит данные привязки объекта управления к посланиям Президента РФ.

Таблица Б.5

Таблица «Послание Президента Проекта»

Атрибут		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Project	Ссылка на родительскую таблицу	GUID			+	-
Послание Президента РФ	Ссылка на справочник Послание Президента РФ	GUID	Справочное поле	Для выбора из справочника послания Президента РФ	+	+

Таблица «Доклад Губернатора Проекта» - дочерняя таблица к «Project». Содержит данные связи объекта управления с докладами Губернатора Пермского края.

Таблица Б.6

Таблица «ДокладГубернатораПроекта»

		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Project	Ссылка на родительскую таблицу	GUID			+	-
Доклад Губернатора ПК	Ссылка на справочник Доклад Губернатора ПК	GUID	Справочное поле	Для выбора из справочника доклада губернатора ПК	+	+

Таблица «Пункт Программы СЭР Проекта» - дочерняя таблица к «Project». Содержит данные связи объекта управления с пунктами справочника «Программа СЭР ПК».

Таблица Б.7

Таблица «Пункт Программы СЭР Проекта»

Атрибут		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Project	Ссылка на родительскую таблицу	GUID			+	-
Пункт Программы СЭР	Ссылка на справочник Пункт Программы СЭР	GUID	Справочное поле	Для выбора из справочника пункта Программы СЭР ПК	+	+

Таблица «Пункт Стратегии СЭР Проекта» - дочерняя таблица к «Project». Содержит данные связи объекта управления с пунктами справочника «Стратегия СЭР ПК»

Таблица Б.8

Таблица «Пункт Стратегии СЭР Проекта»

Атрибут		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Project	Ссылка на родительскую таблицу	GUID			+	-
Пункт Стратегии СЭР	Ссылка на справочник Пункт Стратегии СЭР	GUID	Справочное поле	Для выбора из справочника пункта Стратегии СЭР ПК	+	+

Модель данных блока основных сведений модуля паспортизации объекта управления приведена на рис. Б.1 и рис. Б.2.

Рисунок Б.1 Общая модель данных модуля паспортизации

Рисунок Б.2 Модель данных модуля паспортизации, блок основных сведений

Модуль паспортизации объекта управления, блок «Участники»

Таблица «Project Stake Holder» - дочерняя таблица к «Project». Содержит данные об органах власти, участвующих в реализации объекта управления

Таблица Б.9

Таблица «Project Stake Holder»

Атрибут		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Project	Ссылка на родительскую таблицу	GUID			+	-
Name		tString255	Текстовое поле для ввода вручную			+
Description			Текстовое поле	Описание участника объекта управления	-	+
Organization Unit	Ссылка на справочник Organization Unit	GUID	Справочное поле	Выбор органа власти-участника	+	+
Person	Ссылка на справочник Person	GUID	Справочное поле	Автоматически заполняется данными руководителя ИОГВ - участника объекта.	-	-
ProjectRole	Ссылка на справочник ProjectRole	GUID	Справочное поле	Выбор роли участника: Соисполнитель Участник	+	+
isApprover		bool = false	Чек-бокс		-	+

Таблица «ProjectResource» - дочерняя таблица к «Project». Содержит данные о сотрудниках ИОГВ, входящих в рабочую группу объекта управления.

Таблица Б.10

Таблица «ProjectResource»

Атрибут		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Project	Ссылка на родительскую таблицу	GUID			+	-
Resource	Ссылка на справочник Resource	GUID	Справочное поле	Выбор участника рабочей группы из справочника ресурсов системы	+	+
Description			Текстовое поле	Описание участника объекта управления	-	+
ProjectRole	Ссылка на справочник ProjectRole	GUID	Справочное поле	Выбор роли участника: · Администратор · Руководитель · Исполнитель · Иной	+	+

Модель данных блока «Участники» модуля паспортизации объекта управления приведена на рис. Б.3.

Рисунок Б.3 Модель данный модуля паспортизации, блок «Участники»

Модуль паспортизации объекта управления, блок «Финансирование»

Таблица «Project Finance» - дочерняя таблица к «Project». Содержит данные о финансировании объекта управления в разрезе источников финансирования и лет.

Таблица Б.11

Таблица «Project Finance»

Атрибут		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Project	Ссылка на родительскую таблицу	GUID			+	-
Name		tString255	Текстовое поле для ввода вручную		-	+
Description			Текстовое поле	Описание участника объекта управления	-	+
Start		nDate	Календарь		-	+
Finish		nDate	Календарь		-	+
Period	Ссылка на справочник Period	GUID	Справочное поле	Поле для выбора периода финансирования из справочника периодов.	+	+
Source	Ссылка на справочник Source	GUID	Справочное поле	Поле для выбора источника финансирования из справочника источников	+	+
PlanValue		tDecimal	Текстовое поле для ввода вручную	Поля для ввода плановых значений показателя	+	+
ActualValue		tDecimal	Текстовое поле для ввода вручную	Поля для отображения фактических значений показателя	+

Модель данных блока «Финансирование» модуля паспортизации объекта управления приведена на рис. Б.4.

Рисунок Б.4 Модель данных модуля паспортизации, блок «Финансирование»

Модуль паспортизации объекта управления, блок «Целевые показатели»

Таблица «Project KPI» - дочерняя таблица к «Project». Содержит данные о плановых и фактических значениях целевых показателей объекта.

Таблица Б.12

Таблица «Project KPI»

Атрибут		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Project	Ссылка на родительскую таблицу	GUID			+	-
Name		tString255	Текстовое поле для ввода вручную	-	+
KPI	Ссылка на справочник KPI	GUID	Справочное поле	Поле для выбора показателя из справочника показателей системы	-	+
Description			Текстовое поле для ввода вручную	Описание показателя	-	+
Start		nDate	Календарь		-	+
Finish		nDate	Календарь		-	+
Measure Unit Txt		tString10	Текстовое поле для ввода вручную	Поле для ввода единицы измерения показателя. заполняется автоматически значением атрибута KPI. Measure Unit Txt, если заполнено Project KPI. KPI	+	+
Period	Ссылка на справочник Period	GUID	Справочное поле	Поле для выбора периода финансирования из справочника периодов.	+	+
PlanValue		tDecimal	Текстовое поле для ввода вручную	Поля для ввода плановых значений показателя	+	+
ActualValue		tDecimal	Текстовое поле для ввода вручную	Поля для отображения фактических значений показателя	+
Source	Ссылка на справочник Source	GUID	Справочное поле	Поле для выбора источника финансирования из справочника источников	+	+

Модель данных блока «Целевые показатели» модуля паспортизации объекта управления приведена на рис. Б.5.

Рисунок Б.5 Модель данных модуля паспортизации, блок «Целевые показатели»

Модуль календарного планирования

Таблица «Task» - дочерняя таблица к «Project». Содержит данные о задачах календарного плана объекта управления, их показателях.

Таблица Б.13

Таблица «Task»

Атрибут		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Project	Ссылка на родительскую таблицу	GUID			+	-
Name		tString255	Текстовое поле для ввода вручную	Название задачи календарного плана	+	+
Order		Integer		Порядковый номер задачи в списке. Перевычисляется в соответствии с положением строки задачи	+	-
Description		tString255	Текстовое поле для ввода вручную	Описание задачи	-	+
Status		tString20	Текстовое поле	Автоматически вычисляемое поле. Принимает значение одно из следующих значений в соответствии со значениями атрибутов TaskPercentComplete, Task.ActualFinish: · Достигнута в срок. · Достигнута с нарушением срока · Просрочена. · Запланирована.	+	-
WBScode		tString		Номер задачи в структуре плана. Перевычисляется в соответствии с положением строки задачи и уровнем вложенности	+	-
isSummary		bool		Признак суммарной задачи. Равно «true», если у задачи есть потомок.	-	-
IsMainTask		bool		Признак суммарной задачи объекта. Равно «true», если на задачу ссылается Project.MainTask.	-	-
IsMileStone		bool	Чек-бокс	Признак вехи. Если Task.PlannedDuration = 0, то IsMileStone = true.	-	+
Priority		tInteger			-	+
Planed Start		tDateTime	Календарь	Дата планового начала работы над задачей	+	+
Planned Finish		tDateTime	Календарь	Дата планового завершения работы над задачей	+	+
Base Start		tDateTime
Base Finish		tDateTime
Actual Start		tDateTime
Actual Finish		tDateTime
Planned Duration		tDecimal		Если длительность не введена, принимает значение как разница между датами начала и окончания задачи: [PlannedDuration] = [ PlannedFinish] - [PlanedStart]
BaseDuration		tDecimal
Remaining Duration		tDecimal
ActualDuration		tDecimal
PercentComplete		tInteger		Сведения о текущем состоянии задачи, выраженные как процент завершения для длительности задачи. Передается из процесса отчетности.	+	-
Реквизиты НПА		tString255			-	+
TaskType	Ссылка на справочник TaskType	GUID	Справочное поле		-	+
Задача СЭР	Ссылка на справочник ЗадачаСЭР	GUID	Справочное поле		-	+
Ответственный	Ссылка на справочник OrganizationUnit	GUID	Справочное поле	Заполняется автоматически данными места работы исполнителя задачи	-	+
Портфель Направлений	Ссылка на справочник Портфель Направлений	GUID	Справочное поле		-	+

Таблица «Assignment» - дочерняя таблица к «Task». Содержит данные о назначениях ресурсов на задачу.

Таблица Б.14

Таблица «Assignment»

Атрибут		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Task	Ссылка на родительскую таблицу	GUID			+	-
Description		tString255	Текстовое поле	Описание, комментарий	-	+
PlanedStart		tDateTime	Календарь	Дата планового начала работы над задачей	+	+
PlannedFinish		tDateTime	Календарь	Дата планового завершения работы над задачей	+	+
BaseStart		tDateTime
BaseFinish		tDateTime
ActualStart		tDateTime
ActualFinish		tDateTime
PercentComplete		tInteger			+	-

Таблица «TaskLink» - содержит данные о связях задач между собой.

Таблица Б.15

Таблица «TaskLink»

Атрибут		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Start	Ссылка на Task	GUID	Справочное поле	Выбор предшественника задачи из перечня задач объекта	+	+
Finish	Ссылка на Task	GUID		Принимает значение редактируемой задачи, для которой выбирается предшественник.	+	-
Description		tString255	Текстовое поле для ввода вручную	Описание, комментарий	-	+
LinkType			Поле со списком	Выбор типа связи: · Начало-Начало. · Начало-Окончание. · Окончание-Начало. · Окончание-Окончание.	+	+
Lag		tDecimal	Текстовое поле	По умолчанию равно нулю.	-	+

Таблица «ProgressReport» - содержит данные о результатах достижения вех в процессе отчетности об исполнении вех

Таблица Б.16

Таблица «Progress Report»

Атрибут		В БД	На экранной форме	Назначение	Обязательность	Редактирование
Assignment	Ссылка на Assignment	GUID			+	-
Status			Текстовое поле	Принимает значение в ходе процесса отчетности	+	-
SentTime		tDateTime	Календарь	Принимает значение даты старта процесса отчетности об исполнении.	+	-
Planned Finish		tDateTime	Календарь	Выбор срока исполнения задачи.	-	+
Прогноз			Поле со списком	Поле для выбора прогноза исполнения вех будущих периодов
Percent Complete		tInteger			+	+
Description		tString255	Текстовое поле для ввода вручную	Описание, комментарий исполнителя	+	+

Модель данных модуля календарного планирования приведена на рис. Б.6:

Рисунок Б.6 Модель данных модуля календарного планирования

Модуль управления рисками

Рисунок Б.7 Модель данных модуля управления рисками

Модуль ведения реестра участников проектной деятельности

Рисунок Б.8 Модель данных модуля ведения реестра участников проектной деятельности

ПРИЛОЖЕНИЕ В

 

Схема процесса разработки объекта управления

Рис. В.1 Модель процесса разработки объекта управления

ПРИЛОЖЕНИЕ Г

 

Схема процесса внесения изменений

Рис. Г.1 Схема процесса внесения изменений в проект

ПРИЛОЖЕНИЕ Д

 

Схема процесса отчетности об исполнении вех объекта управления

Рис. Д.1 схема процесса отчетности по исполнению

ПРИЛОЖЕНИЕ Е

 

Регламент информационного обмена данными между ИС УГП и ИАС ПК

В рамках информационного взаимодействия из ИАС ПК в Систему управления государственными программами должны передаваться следующие данные:

·  Данные о пользователях.

·        Справочник органов власти.

·        Кодификатор целей и задач.

·        Справочник целевых показателей социально-экономического развития.

Детальный атрибутный состав передаваемых данных приведен в таблицах ниже

Таблица Е.1

Пользователи

Наименование параметра	Обязательность	Тип параметра	Содержание
primaryKey	Not null	Guid	Уникальный идентификатор пользователя
login	Not null	string, maxLength=20	Логин пользователя	Null	string, maxLength=255	Хэш пароля пользователя (если не доменный)
lastName	Not null	string, maxLength=255	Фамилия пользователя
firstName	Not null	string, maxLength=255	Имя пользователя
middleName	Null	string, maxLength=255	Отчество пользователя
email	Not null	string, maxLength=255	E-mail пользователя
actual	Not null	bool	Признак актуальности (true - действителен, false - недействителен)

Таблица Е.2

Оргструктура (ИОГВ и ФЦБ)

Наименование параметраОбязательностьТип параметраСодержание
primaryKey	Not null	Guid	Уникальный идентификатор элемента оргструктуры
name	Not null	string, maxLength=255	Наименование элемента оргструктуры
shortName	Not null	string, maxLength=100	Краткое наименование элемента оргструктуры
actual	Not null	bool	Признак актуальности (true - действителен, false - недействителен)
hierarchy	Null	Guid	Уникальный идентификатор вышестоящего элементы оргструктуры

Таблица Е.3

Кодификатор целей и задач

Наименование параметраОбязательностьТип параметраСодержание
primaryKey	Not null	Guid	Уникальный идентификатор пункта кодификатора
number	Not null	string, maxLength=20	Номер пункта кодификатора
name	Not null	string, maxLength=255	Наименование пункта кодификатора
actual	Not null	bool	Признак актуальности (true - действителен, false - недействителен)
hierarchy	Null	Guid	Уникальный идентификатор вышестоящего пункта кодификатора

Таблица Е.4

Справочник показателей

Наименование параметраОбязательностьТип параметраСодержание
primaryKey	Not null	Guid	Уникальный идентификатор показателя
name	Not null	string, maxLength=255	Наименование показателя
description	Null	string, maxLength=255	Описание показателя\методика расчета
measureUnit	Null	string, maxLength=10	Единица измерения показателя
direction	Not null	int	Отражает желаемое направление значения показателя: <0 - ожидается снижение; >0 - ожидается повышение
dateValue	Null	DateTime (yyyy-MM-ddTHH:mm:ss)	Дата, на которую передается значение показателя
value	Null	decimal	Значение показателя на указанную дату
actual	Not null	bool	Признак актуальности (true - действителен, false - недействителен)
hierarchy	Null	Guid	Уникальный идентификатор вышестоящего пункта кодификатора

ИС УГП - ИАС ПК

В рамках информационного взаимодействия из ИС УГП управления государственными программами в ИАС ПК должны передаваться следующие данные:

·  Данные об объектах управления.

·        Календарные планы объектов управления.

·        Цели и задачи объектов управления.

·        Показатели объектов управления.

Детальный атрибутный состав передаваемых данных приведен в таблицах ниже:

Таблица Е.5

Объекты

Наименование параметра	Обязательность	Тип параметра	Содержание
primaryKey	Not null	Guid	Уникальный идентификатор объекта
type	Not null	string, maxLength=255	Тип объекта
number	Not null	string, maxLength=20	Номер объекта
name	Not null	string, maxLength=255	Название объекта
fcb	Null	string, maxLength=255	Наименование ФЦБ
manager	Null	string, maxLength=255	фамилия, имя и отчество руководителя
status	Not null	string, maxLength=255	Статус объекта
doer	Null	string, maxLength=255	Наименование ответственного исполнителя
time-frame	Null	DateTime (yyyy-MM-ddTHH:mm:ss)	Срок реализации объекта
startDate	Null	DateTime (yyyy-MM-ddTHH:mm:ss)	Дата начала объекта
finishDate	Null	DateTime (yyyy-MM-ddTHH:mm:ss)	Дата окончания объекта
controlLevels	Null	string, maxLength=max	Уровни контроля объекта, перечисленные через “;”
financeSources	Null	string, maxLength=max	Источники финансирования объекта, перечисленные через “;”
SERStrategies	Null	string, maxLength=max	Пункты стратегии СЭР, связанные с объектом, перечисленные через “;”
SERPrograms	Null	string, maxLength=max	Пункты программы СЭР, связанные с объектом, перечисленные через “;”
customer	Null	string, maxLength=255	Наименование заказчика
presidentsArrangements	Null	string, maxLength=max	Указы президента, связанные с объектом, перечисленные через “;”

Таблица Е.6

План объекта

Наименование параметра	Обязательность	Тип параметра	Содержание
primaryKey	Not null	Guid	Уникальный идентификатор задачи
hierarchy	Null	Guid	Уникальный идентификатор суммарной задачи
name	Not null	string, maxLength=255	Наименование задачи
wbs	Not null	string, maxLength=20	Структурный номер задачи
duration	Not null	Int	Длительность задачи в днях
startDate	Not null	DateTime (yyyy-MM-ddTHH:mm:ss)	Дата начала
finishDate	Not null	DateTime (yyyy-MM-ddTHH:mm:ss)	Дата окончания
baseStartDate	Null	DateTime (yyyy-MM-ddTHH:mm:ss)	Базовая дата начала
baseFinishDate	Null	DateTime (yyyy-MM-ddTHH:mm:ss)	Базовая дата окончания
percentComplete	Not null	Int (0..100)	Процент выполнения задачи
isMilestone	Not null	bool	Признак вехи
actualStartDate	Null	DateTime (yyyy-MM-ddTHH:mm:ss)	Фактическая дата начала
actualFinishDate	Null	DateTime (yyyy-MM-ddTHH:mm:ss)	Фактическая дата окончания
responsible	Null	string, maxLength=255	Наименование ответственного
doer	Null	string, maxLength=255	Наименование исполнителя

Таблица Е.7

Цели и задачи объекта

Наименование параметраОбязательностьТип параметраСодержание
primaryKey	Not null	Guid	Уникальный идентификатор цели или задачи объекта
project	Not null	Guid	Уникальный идентификатор объекта
goalsAndObjectivesPK	Null	Guid	Уникальный идентификатор пункта кодификатора
description	Not null	string, maxLength=255	Текстовое представление цели (необходимо, если цель объекта не связана с кодификатором)

Таблица Е.8

Показатели объекта

Наименование параметраОбязательностьТип параметраСодержание
primaryKey	Not null	Guid	Уникальный идентификатор показателя объекта
project	Not null	Guid	Уникальный идентификатор объекта
kpi	Not null	Guid	Уникальный идентификатор показателя
startDate	Not null	DateTime (yyyy-MM-ddTHH:mm:ss)	Начало периода
finishDate	Not null	DateTime (yyyy-MM-ddTHH:mm:ss)	Окончание периода
planValue	Null	decimal	Плановое значение показателя