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

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

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

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

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

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

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

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

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 - текущая строка в списке согласующих