Проектная деятельность органов власти Пермского края в реализации государственных программ
Глава 1. Проектная деятельность в органах власти Пермского края
1 Участие
органов власти Пермского края в проектной деятельности
2 Описание
процессов проектного управления в органах власти Пермского края
3 Обзор
программных средств управления государственными программами
Выводы по
первой главе
Глава 2. Проектирование ИС УГП
1 Обзор
публикаций по проблеме моделирования бизнес-процессов
2 Требования
к средствам моделирования бизнес-процессов управления проектами
3 Обзор
программных средств моделирования бизнес-процессов
4 Выбор
платформы автоматизации бизнес-процессов с использованием метода вариантных
секторов
5 Анализ
автоматизированных процессов жизненного цикла проекта
6 Требования
к реализации процессов управления объектами в ИС УГП
7 Общие
требования к ИС УГП
9 Требования
к структуре базы данных
Выводы по
второй главе
Глава 3. Взаимодействие ИС УГП с ИАС ПК
1 Описание
Информационной аналитической системы Пермского края
2
Интеграционная платформа Highway SB
3 Состав
передаваемых данных
Выводы по
четвертой главе
Словарь
терминов и сокращений
Приложение А. Описание типовых функций проектных ролей участников проектной деятельности
органов власти и Администрации губернатора Пермского края
Приложение Б. Описание состава атрибутов модели данных ИС УГП управления государственными
программами
Приложение В. Схема процесса разработки объекта управления
Приложение Г. Схема процесса внесения изменений
Приложение Д. Схема процесса отчетности об исполнении вех объекта управления
Приложение Е. Регламент информационного обмена данными между ИС УГП и ИАС ПК
Глава
1. Проектная деятельность в органах власти Пермского края
Первым шагом при проектировании информационной системы является анализ
предметной области, в ходе которого определяются бизнес-процессы, их участники,
выявляются существующие проблемы и определяются подходы к их решению.
В ходе анализа проектной деятельности в органах власти Пермского края
необходимо определить проблемы внедрения проектного управления, участников
проектной деятельности и их роли.
Проектное управление в органах власти и Администрации губернатора
Пермского края начало использоваться еще с 2006 года, когда начали внедряться
приоритетные проекты и развивается постепенно. Создаются нормативные документы,
регламентирующие проектную деятельность, была создана и запущена в промышленную
эксплуатацию Информационно-аналитическая системы управления проектами на
платформе Microsoft ProjectServer (ИАС УП).
На первых порах в системе размещались только планы-графики проектов. В
последствии стали внедряться проекты различных типов: проекты — внешние,
внутренние, приоритетные, «дорожные карты», непроектные мероприятия. С момента
применения к процессу реализации государственных программ методов проектного
управления был создан особый тип проекта — подпрограмма государственной программы. В ИАС УП стали размещаться их план-графики, содержащие мероприятия, основные
мероприятия и вехи подпрограмм. Отдельно создается список контрольно-целевых
показателей с их плановыми и фактическими значениями. Ответственные за
достижение показателей и вех должны вовремя актуализировать информацию о ходе
выполнения поставленных задач в ИАС УП.
В процессе развития ИАС УП был автоматизирован жизненный цикл проекта. С
момента регистрации в ИАС УП нового проекта запускается процесс разработки, в
рамках которого проект проходит стадии планирования и согласования с
заинтересованными сторонами. После согласования и утверждения проекта, он
переходит на этап реализации, в ходе которого ответственные за достижение вех
должны своевременно отчитываться об исполнении. Для этой цели автоматизирован
процесс отчетности об исполнении. Информация исполнителя о достижении вехи
проходит согласование и утверждение у заинтересованных лиц. Для контроля за
изменениями в проекте был автоматизирован процесс внесения изменений.
Параллельно, с внедрением типа проекта «Подпрограмма государственной
программы» в Информационно-аналитической системе Пермского края (ИАС ПК)
начинается контроль достижения показателей государственных программ. В ИАС ПК
ведется перечень подпрограмм и мероприятий и каждой подпрограмме соответствует
перечень целевых показателей. В ИАС ПК ответственные так же должны отчитываться
о ходе достижения целевых показателей. Фактические данные о достижении
показателей так же должны утверждаться заинтересованными сторонами.
Таким образом, процесс реализации государственных программ в органах
власти и Администрации губернатора Пермского края предполагает использование
нескольких информационных систем и дублирование действий ответственных лиц, что
приводит к несогласованности данных и увеличивает трудоемкость по их
актуализации.
1 Участие
органов власти Пермского края в проектной деятельности
Проектное управление в органах власти Пермского края начинает свою
историю с 2006 года, когда на территории Пермского края начали реализовываться
приоритетные региональные проекты «Новая школа», «Муниципальные дороги»,
«Качественное здравоохранение», «Достойное жилье», «Содействие в переселении
граждан из труднодоступных и отдаленных населенных пунктов», а также отдельные
пилотные проекты в сфере развития человеческого потенциала.
В 2007 году была сформирована рабочая группа по развитию системы
проектного управления в органах государственной власти и появились первые
правовые акты об оформлении проектов (распоряжение губернатора Пермского края
№23-р) и реестры проектов. Органы власти были объединены в
функционально-целевые блоки и функциональные блоки. Указом губернатора
Пермского края №55 для каждого блока были установлены цели, задачи, и проекты,
обеспечивающие их реализацию, а также целевые показатели, которые позволяли
оценить степень достижения целей и задач.
В 2011-2012 годах в структуре управления регионом были также выделены
проектные блоки, объединяющие задачи и полномочия нескольких
функционально-целевых блоков (комплексные функционально-целевые направления),
после достижения поставленных целей данные блоки были расформированы.
В 2010 году распоряжением Правительства Пермского края №44-рп был
утвержден План мероприятий Правительства по реализации приоритетных направлений
социально-экономического развития Пермского края.
В соответствии с распоряжением председателя Правительства Пермского края
от 26. 2011 г. №8-рпп «О Регламенте процесса оперативного планирования по
проектам, целевым программам и непроектным мероприятиям на основе технологии
Microsoft ProjectServer» все проекты, программы и непроектные мероприятия стали
реализовываться с использованием Информационно-аналитической системы управления
проектами (далее — ИАС УП).
После утверждения Плана правовым актом, планы-графики стали размещаться в
Microsoft Project и оперативное планирование по ним осуществлялось в ИАС УП. Когда было утверждено распоряжение председателя Правительства Пермского края от
31. 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 государственные программы.
Управление
социально-экономическим развитием Пермского края осуществляется на основе
принципов стратегического планирования, включающих следующие основные фазы:
целеполагание, прогнозирование, планирование и программирование.
· управляет процессом разработки стратегии и программы
социально-экономического развития Пермского края, включая подготовку и
обоснование принципов социально-экономического развития и контроль их
исполнения;
· управляет процессом подготовки программы
социально-экономического развития Пермского края;
· осуществляет мониторинг результативности плана мероприятий Правительства
Пермского края по социально-экономическому развитию Пермского края;
· по результатам реализации плана мероприятий Правительства
Пермского края по социально-экономическому развитию Пермского края и программы
социально-экономического развития Пермского края готовит рекомендации для
внесения корректировок в соответствующие документы;
· организует подготовку ежегодных посланий губернатора о
социально-экономическом и политическом положении в Пермском крае;
· осуществляет проведение регулярного мониторинга, анализ и
прогнозирование социально-экономического развития Пермского края, в том числе с
использованием информационных систем, организует сбор необходимой для этого
информации и ее обработку,
· управляет процессом планирования целей, задач и целевых показателей
деятельности Правительства Пермского края по социально-экономическому развитию
Пермского края;
· обеспечивает соответствие приоритетных проектов и программ,
реализуемых исполнительными органами государственной власти Пермского края,
поставленным целям, задачам и целевым показателям;
· обеспечивает подготовку документов, аналитических материалов
и соответствующих проектов актов губернатора, определяющих цели, задачи и
целевые показатели деятельности Правительства Пермского края;
· организует мониторинг и контроль достижения плановых значений
целевых показателей деятельности исполнительных органов государственной власти
Пермского края, выполнения проектов и программ, характеризующих исполнение
программы социально-экономического развития Пермского края;
· организует мониторинг и контроль соответствия затрачиваемых
ресурсов и принимаемых управленческих решений установленным целям, задачам и
целевым показателям деятельности исполнительных органов государственной власти
Пермского края в рамках управленческого бюджета.
3 Обзор
программных средств управления государственными программами
Среди большого количества информационных средств, автоматизирующих
процессы проектного управления, стали появляться и программные средства для
автоматизации процесса управления государственными программами.
К функциональным возможностям системы относятся:
· Сбор и/или формирование заявок органов исполнительной власти г. Москвы на
автоматизацию/модернизацию/развитие (основание для инициации проектов).
· Включение проектов в План работ по информатизации, в том
числе согласование объемов финансирования.
· Ведение паспортов проектов.
· Контроль сроков реализации проектов, в том числе
формирование, публикация, актуализация календарных планов.
· Учет финансовых показателей проектов.
· Хранение документации по проектам.
· Назначение на роли участников проектов.
· Формирование отчетов о ходе реализации проектов и об
исполнительской дисциплине в утвержденных формах.
· Оповещение участников о событиях в проекте.
· Мониторинг целевых показателей проектов.
Можно сделать вывод, что государственная программа в этой информационной
системе тоже принимает функции проекта и к ней применяются действия,
характерные для проекта:
· Разработка паспорта.
· Формирование и актуализация календарного плана.
· Контроль сроков.
· Управление ресурсами программы.
· Управление рисками.
Функциональные
возможности «ПМ Форсайт» достаточно обширны, т. система модульная.
Автоматизированы
процессы календарного планирования, управления рисками, продуктами, финансами,
показателями, ресурсами, документооборота, управления поручениями, процессами и
мероприятиями, договорами.
В
результате анализа нескольких представленных в сети Интернет описаний
информационных систем автоматизации управления государственными программами
можно сделать вывод, что не существует единого решения. Есть несколько
продуктов, разработанных на платформах систем автоматизации управления
проектами.
1 Обзор
публикаций по проблеме моделирования бизнес-процессов
В научных статьях неоднократно поднималась проблема моделирования
процессов.
В
различных публикациях моделированию бизнес-процессов организации отводится
важная роль. Основная его цель — систематизация знаний о компании и ее
бизнес-процессах в наглядной графической форме, более удобной для анализа. При
этом моделирование бизнес-процессов решает ряд задач, таких как выявление
текущих проблем на предприятии и предвидения будущих. Кроме выявления проблем
на предприятии моделирование позволяет определить стоимость как каждого
процесса, так и всех в совокупности.
Моделированию
и совершенствованию бизнес-процессов в различных областях посвящено множество
исследований российских и зарубежных ученых.
2 Требования
к средствам моделирования бизнес-процессов управления проектами
Для облегчения управления моделями бизнес-процессов, отслеживания в них
изменений и сокращения времени анализа используются различные программные
средства моделирования.
Для дальнейшего исследования и апробации предполагается использование не
только средств моделирования бизнес-процессов, но и платформы, реализующей
автоматизированные процессы управления проектом. То есть для решения
поставленной задачи исследования система моделирования бизнес-процессов должна
обладать следующими функциями:
· Дизайнер для моделирования бизнес-процессов с использованием стандартов
моделирования. Предпочтение отдается стандарту BPMN.
· Простой графический интерфейс.
· Репрезентативность моделей.
· Русскоязычный интерфейс (желательно).
· Web-интерфейс.
· Наличие пользовательской документации.
· Возможность задавать различные специфические технические
аспекты процесса — продолжительность транзакции, сообщения и уведомления в
рамках процесса, и проектировать интерфейсы взаимодействия с другими системами. Это обусловлено необходимостью инициализации переменных процесса в зависимости
от параметров объекта управления: типа, ответственного исполнителя. процесс должен в автоматизированном режиме определять участников процесса и
назначать им задачи.
· Механизм исполнения.
· Возможности быстрого изменения бизнес-процессов.
· Возможность контроля каждого экземпляра процесса.
· Простота в освоении.
· Полностью opensource.
3 Обзор
программных средств моделирования бизнес-процессов
Для анализа функциональных возможностей были выбраны следующие средства
моделирования бизнес-процессов, удовлетворяющие требованию свободного
распространения:
· Bizagi BPM Suite.
· ELMA BPM.
· Bonita Open Solution.
· jBPM.
Перечисленные системы моделирования достаточно популярны и востребованы,
поддерживают стандарт BPMN.
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 — дизайнер бизнес-процессов
распространяется бесплатно.
2 ELMA BPM
ELMA BPM — разработка российской компании ELMA, предназначенная для
управления бизнес-процессами.
После создания графической модели, выбора параметров процесса и
определения данных, с которыми работает бизнес-процесс, он публикуется на
сервере системы и становится исполнимым в веб-интерфейсе. Каждый запущенный
экземпляр бизнес-процесса создает пользователям системы формы задач, в которых
они должны отчитываться о своей деятельности. Эти формы гибко настраиваются.
В ELMA поддерживается импорт и экспорт в формат XPDL — это универсальный
формат, который позволяет выгружать и загружать модели бизнес-процессов.
Кроме того, в системе ELMA реализована отладка процессов и инструменты
для их тестирования (верификации). При публикации модели процесса автоматически
выполняется проверка правильности модели и проверка сценариев на наличие
ошибок.
3 Bonita Open Solution
Bonita Open Solution — инструмент моделирования
французских разработчиков, не имеющий российской локализации.
Решение состоит из трёх основных компонентов, разделенных по назначению:
· Studio — редактор бизнес-процессов.
· Execution Engine — инструмент для исполнения
бизнес-процессов.
К основным функциям платформы относится:
· Создание бизнес-процессов из элементарных шагов.
· Создание переменных для доступа, манипуляций и управления
данными в бизнес-процессе.
· Создание цепочек бизнес-процессов.
· Назначение ролей и исполнителей на роли в бизнес-процессе.
Моделирование процессов Bonita Open Solution происходит в нотации BPMN.
К достоинствам Bonita Studio относится моделирование и автоматизация
процесса в одном окне и высокая степень визуализации бизнес-процессов/
4 jBPM
Его
наиболее заметные признаки перечислены ниже:
· Настраиваемый, встраиваемый, легковесный редактор процессов.
· Домен ориентированные процессы и правила.
· Независимый сервис управлением поручениями.
· Веб интерфейс позволяет создавать BPMN2 процессы, разворачивать, управлять; строить отчеты (BIRT), управлять поручениями.
· Сохранение состояния процесса в его промежуточной точке.
· Возможность асинхронного исполнения процессов.
· Версионность описания процесса.
· Заведение в системе пользователей, назначение им заданий.
· Поддержка рассылки e-mail сообщений о назначении пользователям
заданий.
· Интерфейс администратора, позволяющий отслеживать состояния
запущенных процессов и тех, что уже исполнились.
· Возможность использования скриптового языка jUEL.
· Запуск как отдельным приложением, так и внутри приложения.
· Возможность отслеживания каждого экземпляра процесса.
4 Выбор
платформы автоматизации бизнес-процессов с использованием метода вариантных
секторов
Сравнительный функциональный анализ программных средств моделирования
бизнес-процессов
Вес критерия
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.
5 Анализ
автоматизированных процессов жизненного цикла проекта
Как было сказано выше, для автоматизации жизненного цикла проектов в ИАС
УП реализованы бизнес-процессы управления проектами. Ниже приводится их
описание, анализ и рекомендации по модернизации.
1 Инициация
объекта управления
Целью инициации проекта является принятие решения о необходимости его
реализации, назначение руководителя и регистрация проекта в ИАС УП. В ходе
процесса инициации инициатор объекта управления готовит в произвольной форме
предложение о необходимости реализации программы, «дорожной карты», проекта,
непроектного мероприятия.
Руководитель функционально-целевого/функционального блока принимает
решение о формализации предложений инициатора для рассмотрения на
межведомственной комиссии по планированию СЭР ПК.
Межведомственная комиссия по планированию СЭР ПК рассматривает
формализованное предложение о необходимости реализации объекта управления. В
случае положительного решения о реализации объекта управления определяет
уровень контроля и тип объекта управления (подпрограмма, проект, «дорожная
карта», непроектное мероприятие).
Руководитель ИОГВ, ответственного за достижение результатов проекта правовым
актом назначает Руководителя и Администратора «дорожной карты», проекта,
программы, непроектного мероприятия.
Завершающим этапом процесса инициации является регистрация объекта
управления в ИАС УП.
процесс инициации в ИАС УП заключается только в заполнении и
сохранении заявки на регистрацию проекта, принято решение при моделировании
объединить его с процессом планирования и согласования.
2 Планирование
и согласование объекта управления
Процесс планирования проекта предназначен для формирования календарного
плана проекта, назначения ответственных за реализацию мероприятий проекта и
достижения контрольных событий, выстраивания иерархической структуры работ,
определения сроков, связей и зависимостей между задачами, планирования затрат
на проект и рисков, влияющих на реализацию проекта.
Процесс планирования проекта предполагает:
· Ввод сведений о проекте.
· Разработку иерархической структуры задач плана-графика
проекта по выбранному шаблону.
· Планирование сроков.
· Планирование ресурсов (исполнителей и ответственных по
задачам).
· Ввод данных о финансировании в разрезе источников.
· Занесение рисков проекта.
· Определение контрольных событий проекта.
· Формирование списка лиц, согласующих проектную документацию.
· Согласование проектной документации.
Планирование проекта осуществляется в рамках задачи по разработке
проекта, которая может быть, как исполнена инициатором проекта самостоятельно,
так и перенаправлена или делегирована другому исполнителю.
Разработка проекта включает в себя ввод сведений о проекте и планирование
работ, ресурсов, рисков с использованием приложения Microsoft Project Professional.
Форма задачи по разработке содержит модуль «Мастера разработки», который
позволяет пошагово занести необходимую информацию о проекте в ИАС УП.
Разработка проекта начинается с заполнения раздела «Сведения о проекте»,
на основе данных которого автоматически формируется Паспорт проекта.
Далее заполняется План-график проекта с использованием настольного
приложения Microsoft Project. Приложение позволяет структурировать намеченные
мероприятия, разбив их на блоки работ, обозначить сроки начала и завершения
мероприятий и определить контрольные события, являющиеся результатами их
реализации, назначить на мероприятие финансовые и трудовые ресурсы.
Планирование бюджета и отслеживание финансирования проекта возможно за
счет использования специальных представлений и таблиц приложения MS Project Professional. При планировании бюджета проекта
финансовый план на текущий год формируется с поквартальной разбивкой, на годы
планового периода планируется общая сумма по году.
После утверждения проектной документации плановые затраты становятся
базовыми. Руководитель периодически обеспечивает занесение фактических данных. Базовые затраты сопоставляются с фактическими.
Отдельным пунктом Мастера разработки является занесение рисков (вопросов)
проекта, которые связываются с мероприятиями, подверженными их влиянию. Для
рисков определяется их содержание, уровень, вероятность наступления, ожидаемая
дата наступления, варианты снятия и минимизации, ответственные за работы по
снятию и минимизации риска. Планирование рисков происходит с использованием
веб-формы карточки риска.
Результатом процесса планирования реагирования на риски являются:
· Перечень рисков, способных повлиять на реализацию проекта в целом и
достижение отдельных результатов.
· Установление степени вероятности наступления риска.
· Установление связи риска с результатом (результатами),
который (-ые) могут быть не достигнуты в случае наступления риска.
· Определение вариантов снятия/минимизации риска (планы
реагирования на риск) и оценочной стоимости снятия/минимизации риска.
· Определение ответственного за работу по снятию/минимизации
риска.
· Включение в План-график упреждающих задач (работ) по
реагированию на риск.
После завершения предыдущих шагов становится возможным формирование
проектной документации — Паспорт и План-график проекта — на основе занесенных
данных.
Паспорт проекта формируется автоматически по утвержденной форме на
основании занесенных в ИАС УП сведений о проекте, реестра рисков, а также блоков
работ и вех из Плана-графика.
Завершающим шагом Мастера-разработки является формирование списка лиц,
согласующих проект. В нем могут быть указаны члены рабочей группы проекта,
представители Проектного офиса и т. В обязательном порядке проект Паспорт и
План-график проекта согласуются с Заказчиком.
План-график и Паспорт проекта запускается на согласование в ИАС УП
Руководителем после прохождения технической экспертизы.
Согласование проекта осуществляется путём последовательного назначения
задач по согласованию проекта всем лицам, указанным в списке согласующих
проекта.
Каждый согласующий имеет право отклонить Паспорт и План-график проекта на
доработку, указав причины отклонения в комментариях к задаче по согласованию. В
этом случае исполнителю задачи по разработке проекта назначается задача по
доработке проекта.
После завершения доработки проект снова переходит на стадию согласования.
Утверждение Плана-графика и Паспорта осуществляется Заказчиком в ИАС УП
после согласования всеми согласующими.
После утверждения проектной документации в ИАС УП Заказчиком Системным
администратором ИАС УП сохраняется Базовый план, проект переходит на стадию
исполнения.
Таким образом, процесс инициации и разработки проекта проходит в
несколько этапов:
Создание заявки на регистрацию проекта
Доработка проекта (при необходимости)
Участниками процесса являются:
· Инициатор — пользователь заполнивший заявку на регистрацию проекта в ИАС
УП.
· Согласующий — пользователь, выбранный ответственным за
согласование проекта. Количество согласующих зависит от типа проекта. Но все
они выполняют одну и ту же функцию согласования. Поэтому объединены в одну
роль.
· Администратор системы — сотрудник службы технической поддержки.
· ИАС УП.
В ходе анализа процесса инициации и разработки было выявлены следующие
недостатки:
После сохранения заявки на регистрацию проекта инициация процесса
планирования и согласования происходит в течение 25-30 мин, что недопустимо,
т. вызывает негативное отношение пользователя, ответственного за размещение
проекта в ИАС УП.
В рамках исполнения задачи по планированию или согласованию проекта
исполнитель не имеет возможности перенаправить задачу другому пользователю,
т. это не предусмотрено процессом.
В число участников процесса входит Администратор системы,
выполняющий функцию сохранения базового плана проекта. эту функция
целесообразно автоматизировать.
Модель
процесса AS IS с обозначенными проблемными местами приведена на рис. рис. Проблемные блоки выделены красным цветом.
На
рис. 2 приведена модель процесса TO BE.
3 Исполнение
проекта
Целью процесса исполнения проекта является актуализация данных о
результатах реализации проекта. Процесс исполнения проекта предполагает:
· Ввод исполнителем фактических данных об исполнении вех и запуск процесса
реализации.
· Согласование внесенной информации заинтересованными
сторонами.
· Актуализация фактических данных об исполнении вех в
плане-графике проекта.
Рисунок
2. 1 Модель процесса инициации и разработки проекта AS IS с выделенными
проблемными блоками
Рисунок
2. 2 Модель процесса инициации и разработки проекта TO BE
· Инициатор — пользователь, ответственный за достижение вехи.
· Согласующий — пользователь, выбранный ответственным за
согласование и утверждение фактических данных о достижении вехи. Все они
выполняют одну и ту же функцию согласования. Поэтому объединены в одну роль.
Исполнение проекта, ввиду своей природы, происходит вне системы, однако
участники проектов регулярно отчитываются в системе о достигнутых результатах в
рамках процесса реализации. В Планах-графиках проектов в ИАС УП закреплена
персональная ответственность участников проекта за достижение контрольных
событий. Ответственным за достижение вех предоставляется возможность
отчитываться о результатах, а также прогнозировать их достижение через ИСУП,
инициируя процессы реализации.
Процесс реализации предоставляет возможность внесения в систему
информации о достижении контрольных событий или прогнозе достижения контрольных
событий путем заполнения веб-формы, прикрепления подтверждающих документов, а
также запуска согласования введенной информации. При этом прикрепленный
подтверждающий документ размещается на сайте проекта и автоматически
ассоциируется с вехой, по которой был запущен процесс реализации.
Подтверждение достижения/недостижения вехи осуществляется с помощью
последовательного назначения задач по согласованию фактических данных всем
лицам, указанным в списке согласующих при инициации процесса реализации. Каждый
согласующий имеет возможность как согласовать, так и отклонить фактические
данные по исполнению проекта, указав причины отклонения в комментариях к задаче
по согласованию. В случае отклонения фактических данных необходимо завершить
процесс и инициировать новый процесс реализации по отклоненной вехе.
В ходе анализа процесса реализации были выявлены следующие недостатки:
Исполнитель задачи по согласованию фактических данных не имеет
возможности перенаправить задачу другому исполнителю, т. это не предусмотрено
процессом.
После отклонения фактических данных с этапа согласования инициатору
процесса назначается задача «Фактические данные были отклонены», в рамках
которой не предусмотрено никаких действий и она носит характер уведомления. Пользователь должен ее просто завершить. В большинстве случаев это не
происходит и процессы в системе остаются незавершенными. В этом случае
сотрудник проектного офиса департамента мониторинга Администрации губернатора
Пермского края направляет заявку о завершении процессов в службу технической
поддержки, и администратор системы завершает их. в периоды формирования
отчетности в системе ежедневно исполняется около 500 процессов реализации и
часть из них остается незавершенными, это влияет на производительность системы. Кроме этого требует времени администратора системы. Таким образом, из-за
отсутствия функциональности операцию завершения процесса инициатором с использованием
соответствующей задачи в случае отклонения фактических данных можно исключить
из процесса. Вместо этого система должна отправлять инициатору уведомление на
e-mail об отклонении отчетности об исполнении и завершать процесс.
Модель
процесса AS IS на рис. Проблемные блоки выделены красным цветом.
На
рис. приведена модель процесса TO BE.
Рисунок
2. 3 Модель AS IS процесса реализации с
выделенными проблемными блоками
Рисунок
2. 4 Модель TO BE процесса реализации
4 Управление
изменениями проекта
Процесс управления изменениями предназначен для корректировки сведений о
проекте, его мероприятиях, сроках, участниках, рисках, затратах.
Процесс управления изменениями предполагает:
· Формирование запросов на изменение проектной документации исполнителями
проектов.
· Согласование запросов с заинтересованными сторонами.
· Внесение изменений в сроки реализации контрольных событий по
проекту, бюджет проекта или прогнозные значений проекта.
· Согласование внесенных изменений.
В перечень участников процесса входят:
· Инициатор — исполнитель проекта, ответственный за изменение его данных.
· Согласующие — сотрудники органов власти, контролирующие
актуальность проектной документации. Список согласующих запрос на изменение и
согласующих внесенные изменения один и тот же.
· Администратор системы — сотрудник службы технической
поддержки.
Процесс «Управление изменениями» предусматривает формирование запросов на
изменение проектной документации исполнителями проектов и обеспечивает
согласование запросов с заинтересованными сторонами.
В ИАС УП реализованы согласование и отклонение запроса на доработку, его
редактирование и повторный запуск согласования изменений.
Основанием для внесения изменений в План-график и Паспорт проекта
является изменение исходных данных и условий, на основе которых осуществлялась
подготовка проекта.
Изменения подлежат последовательному согласованию в ИАС УП с лицами,
установленными на этапе формирования запроса на изменение (при наличии
установленных согласующих) после завершения проверки запроса.
После завершения последовательного согласования запроса на изменение в
ИАС УП инициатору запроса предоставляются права на редактирование проекта. В
рамках задачи по внесению согласованных изменений инициатор процесса имеет
возможность изменить сведения о проекте, внести изменения в План-график,
изменить данные по рискам, скорректировать реестр показателей проекта и их
плановых значений.
Внесенные изменения должны пройти процедуру согласования
заинтересованными сторонами, определенными на этапе формирования запроса на
изменение.
После согласования внесенных изменений предусмотрено сохранение новой
версии базового плана администратором системы.
Кроме этого процесс «Управление изменениями» в ИАС УП предназначен и для
завершения или приостановки проекта, в ходе которого происходит смена статуса
проекта на указанный в запросе и перенос его в архив проектов.
Процесс завершения предполагает:
· Формирование запроса на изменение статуса проекта Руководителем проекта.
· Согласование запроса с заинтересованными сторонами.
· Изменение статуса проекта.
· Перенос проекта в архив проектов.
При завершении проекта, инициатор на форме запроса указывает необходимость
смены статуса и выбирает новый статус проекта «Приостановлен» или «Завершен». После согласования запроса заинтересованными сторонами инициатору на этапе
внесения изменений назначается задача «Внести согласованные изменения», в
рамках которой он не вносит никаких изменений, а просто завершает задачу.
Далее на этапе согласования внесенных изменений согласующий так же должен
завершить задачу без выполнения действий согласования, т. никаких изменений
не вносилось.
Администратор системы должен тоже завершить свою задачу по сохранению
базового плана без выполнения действий с проектом.
Только после этого система меняет статус проекта на указанный в запросе
инициатором.
В ходе анализа процесса «Управление изменениями» было выявлены следующие
недостатки:
В рамках исполнения задачи по внесению изменений, доработке внесенных
изменений, согласованию запроса на изменение или согласованию внесенных
изменений исполнитель не имеет возможности перенаправить задачу другому
пользователю, т. это не предусмотрено процессом.
В число участников процесса входит Администратор системы, выполняющий
функцию сохранения базового плана проекта. эту функция целесообразно
автоматизировать, т. использование человеческих ресурсов влечет
дополнительные расходы.
В связи с частыми случаями некорректного внесения изменений
пользователями необходимо в процесс добавить этап технической экспертизы,
который должен стать первым шагом согласования внесенных изменений.
При завершении проекта в системе из процесса можно исключить три
этапа, которые не представляют значимости для проекта. Это этап внесения
изменений, этап согласования внесенных изменений и этап сохранения базового
плана. Вместо этого после согласования запроса на изменение статуса проекта
система должна изменить статус проекта и завершить процесс.
На
рис. 5 и рис. 6 приведены модели AS IS и TO BE процесса «Управления
изменениями» проекта.
Рисунок
2. 5 Модель AS IS процесса «Управление изменениями» с выделенными
проблемными блоками
Рисунок
2. 6 Модель TO BE процесса «Управление изменениями»