Проектная деятельность органов власти Пермского края в реализации государственных программ
Анализ проектной деятельности Администрации губернатора Пермского края. Программное обеспечение процессов управления государственными программами, роли и функции участников. Требования к информационной системе и средствам моделирования бизнес-процессов.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 30.06.2017 |
| Размер файла | 2,9 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
· Возможность использования скриптового языка 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 |
10 |
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. При планировании бюджета проекта финансовый план на текущий год формируется с поквартальной разбивкой, на годы планового периода планируется общая сумма по году.
После утверждения проектной документации плановые затраты становятся базовыми. Руководитель периодически обеспечивает занесение фактических данных. Базовые затраты сопоставляются с фактическими.
Отдельным пунктом Мастера разработки является занесение рисков (вопросов) проекта, которые связываются с мероприятиями, подверженными их влиянию. Для рисков определяется их содержание, уровень, вероятность наступления, ожидаемая дата наступления, варианты снятия и минимизации, ответственные за работы по снятию и минимизации риска. Планирование рисков происходит с использованием веб-формы карточки риска.
Результатом процесса планирования реагирования на риски являются:
· Перечень рисков, способных повлиять на реализацию проекта в целом и достижение отдельных результатов.
· Установление степени вероятности наступления риска.
· Установление связи риска с результатом (результатами), который (-ые) могут быть не достигнуты в случае наступления риска.
· Определение вариантов снятия/минимизации риска (планы реагирования на риск) и оценочной стоимости снятия/минимизации риска.
· Определение ответственного за работу по снятию/минимизации риска.
· Включение в План-график упреждающих задач (работ) по реагированию на риск.
После завершения предыдущих шагов становится возможным формирование проектной документации - Паспорт и План-график проекта - на основе занесенных данных.
Паспорт проекта формируется автоматически по утвержденной форме на основании занесенных в ИАС УП сведений о проекте, реестра рисков, а также блоков работ и вех из Плана-графика.
Завершающим шагом Мастера-разработки является формирование списка лиц, согласующих проект. В нем могут быть указаны члены рабочей группы проекта, представители Проектного офиса и т.п. В обязательном порядке проект Паспорт и План-график проекта согласуются с Заказчиком.
План-график и Паспорт проекта запускается на согласование в ИАС УП Руководителем после прохождения технической экспертизы.
Согласование проекта осуществляется путём последовательного назначения задач по согласованию проекта всем лицам, указанным в списке согласующих проекта.
Каждый согласующий имеет право отклонить Паспорт и План-график проекта на доработку, указав причины отклонения в комментариях к задаче по согласованию. В этом случае исполнителю задачи по разработке проекта назначается задача по доработке проекта.
После завершения доработки проект снова переходит на стадию согласования.
Утверждение Плана-графика и Паспорта осуществляется Заказчиком в ИАС УП после согласования всеми согласующими.
После утверждения проектной документации в ИАС УП Заказчиком Системным администратором ИАС УП сохраняется Базовый план, проект переходит на стадию исполнения.
Таким образом, процесс инициации и разработки проекта проходит в несколько этапов:
1. Создание заявки на регистрацию проекта
2. Планирование проекта
3. Согласование проекта
4. Доработка проекта (при необходимости)
5. Завершение процесса
Участниками процесса являются:
· Инициатор - пользователь заполнивший заявку на регистрацию проекта в ИАС УП.
· Согласующий - пользователь, выбранный ответственным за согласование проекта. Количество согласующих зависит от типа проекта. Но все они выполняют одну и ту же функцию согласования. Поэтому объединены в одну роль.
· Администратор системы - сотрудник службы технической поддержки.
· ИАС УП.
В ходе анализа процесса инициации и разработки было выявлены следующие недостатки:
1. После сохранения заявки на регистрацию проекта инициация процесса планирования и согласования происходит в течение 25-30 мин, что недопустимо, т.к. вызывает негативное отношение пользователя, ответственного за размещение проекта в ИАС УП.
2. В рамках исполнения задачи по планированию или согласованию проекта исполнитель не имеет возможности перенаправить задачу другому пользователю, т.к. это не предусмотрено процессом.
3. В число участников процесса входит Администратор системы, выполняющий функцию сохранения базового плана проекта. эту функция целесообразно автоматизировать.
Модель процесса AS IS с обозначенными проблемными местами приведена на рис. рис. 2.1. Проблемные блоки выделены красным цветом.
На рис. 2.2 приведена модель процесса TO BE.
2.5.3 Исполнение проекта
Целью процесса исполнения проекта является актуализация данных о результатах реализации проекта. Процесс исполнения проекта предполагает:
· Ввод исполнителем фактических данных об исполнении вех и запуск процесса реализации.
· Согласование внесенной информации заинтересованными сторонами.
· Актуализация фактических данных об исполнении вех в плане-графике проекта.
Рисунок 2.1 Модель процесса инициации и разработки проекта AS IS с выделенными проблемными блоками
Рисунок 2.2 Модель процесса инициации и разработки проекта TO BE
Участниками процесса являются:
· Инициатор - пользователь, ответственный за достижение вехи.
· Согласующий - пользователь, выбранный ответственным за согласование и утверждение фактических данных о достижении вехи. Все они выполняют одну и ту же функцию согласования. Поэтому объединены в одну роль.
· ИАС УП.
Исполнение проекта, ввиду своей природы, происходит вне системы, однако участники проектов регулярно отчитываются в системе о достигнутых результатах в рамках процесса реализации. В Планах-графиках проектов в ИАС УП закреплена персональная ответственность участников проекта за достижение контрольных событий. Ответственным за достижение вех предоставляется возможность отчитываться о результатах, а также прогнозировать их достижение через ИСУП, инициируя процессы реализации.
Процесс реализации предоставляет возможность внесения в систему информации о достижении контрольных событий или прогнозе достижения контрольных событий путем заполнения веб-формы, прикрепления подтверждающих документов, а также запуска согласования введенной информации. При этом прикрепленный подтверждающий документ размещается на сайте проекта и автоматически ассоциируется с вехой, по которой был запущен процесс реализации.
Подтверждение достижения/недостижения вехи осуществляется с помощью последовательного назначения задач по согласованию фактических данных всем лицам, указанным в списке согласующих при инициации процесса реализации. Каждый согласующий имеет возможность как согласовать, так и отклонить фактические данные по исполнению проекта, указав причины отклонения в комментариях к задаче по согласованию. В случае отклонения фактических данных необходимо завершить процесс и инициировать новый процесс реализации по отклоненной вехе.
После согласования фактических данных о достижении контрольного события (прогнозе достижения контрольного события) внесенный в рамках процесса реализации комментарий связывается с задачей и впоследствии доступен для просмотра в отчетах по проекту.
В ходе анализа процесса реализации были выявлены следующие недостатки:
1. Исполнитель задачи по согласованию фактических данных не имеет возможности перенаправить задачу другому исполнителю, т.к. это не предусмотрено процессом.
2. После отклонения фактических данных с этапа согласования инициатору процесса назначается задача «Фактические данные были отклонены», в рамках которой не предусмотрено никаких действий и она носит характер уведомления. Пользователь должен ее просто завершить. В большинстве случаев это не происходит и процессы в системе остаются незавершенными. В этом случае сотрудник проектного офиса департамента мониторинга Администрации губернатора Пермского края направляет заявку о завершении процессов в службу технической поддержки, и администратор системы завершает их. Т.к. в периоды формирования отчетности в системе ежедневно исполняется около 500 процессов реализации и часть из них остается незавершенными, это влияет на производительность системы. Кроме этого требует времени администратора системы. Таким образом, из-за отсутствия функциональности операцию завершения процесса инициатором с использованием соответствующей задачи в случае отклонения фактических данных можно исключить из процесса. Вместо этого система должна отправлять инициатору уведомление на e-mail об отклонении отчетности об исполнении и завершать процесс.
Модель процесса AS IS на рис. 2.3. Проблемные блоки выделены красным цветом.
На рис. 2.4. приведена модель процесса TO BE.
Рисунок 2.3 Модель AS IS процесса реализации с выделенными проблемными блоками
Рисунок 2.4 Модель TO BE процесса реализации
2.5.4 Управление изменениями проекта
Процесс управления изменениями предназначен для корректировки сведений о проекте, его мероприятиях, сроках, участниках, рисках, затратах.
Процесс управления изменениями предполагает:
· Формирование запросов на изменение проектной документации исполнителями проектов.
· Согласование запросов с заинтересованными сторонами.
· Внесение изменений в сроки реализации контрольных событий по проекту, бюджет проекта или прогнозные значений проекта.
· Согласование внесенных изменений.
В перечень участников процесса входят:
· Инициатор - исполнитель проекта, ответственный за изменение его данных.
· Согласующие - сотрудники органов власти, контролирующие актуальность проектной документации. Список согласующих запрос на изменение и согласующих внесенные изменения один и тот же.
· Администратор системы - сотрудник службы технической поддержки.
· ИАС УП.
Процесс «Управление изменениями» предусматривает формирование запросов на изменение проектной документации исполнителями проектов и обеспечивает согласование запросов с заинтересованными сторонами.
В ИАС УП реализованы согласование и отклонение запроса на доработку, его редактирование и повторный запуск согласования изменений.
Основанием для внесения изменений в План-график и Паспорт проекта является изменение исходных данных и условий, на основе которых осуществлялась подготовка проекта.
Изменения подлежат последовательному согласованию в ИАС УП с лицами, установленными на этапе формирования запроса на изменение (при наличии установленных согласующих) после завершения проверки запроса.
После завершения последовательного согласования запроса на изменение в ИАС УП инициатору запроса предоставляются права на редактирование проекта. В рамках задачи по внесению согласованных изменений инициатор процесса имеет возможность изменить сведения о проекте, внести изменения в План-график, изменить данные по рискам, скорректировать реестр показателей проекта и их плановых значений.
Внесенные изменения должны пройти процедуру согласования заинтересованными сторонами, определенными на этапе формирования запроса на изменение.
После согласования внесенных изменений предусмотрено сохранение новой версии базового плана администратором системы.
Кроме этого процесс «Управление изменениями» в ИАС УП предназначен и для завершения или приостановки проекта, в ходе которого происходит смена статуса проекта на указанный в запросе и перенос его в архив проектов.
Процесс завершения предполагает:
· Формирование запроса на изменение статуса проекта Руководителем проекта.
· Согласование запроса с заинтересованными сторонами.
· Изменение статуса проекта.
· Согласование внесенных изменений.
· Перенос проекта в архив проектов.
При завершении проекта, инициатор на форме запроса указывает необходимость смены статуса и выбирает новый статус проекта «Приостановлен» или «Завершен». После согласования запроса заинтересованными сторонами инициатору на этапе внесения изменений назначается задача «Внести согласованные изменения», в рамках которой он не вносит никаких изменений, а просто завершает задачу.
Далее на этапе согласования внесенных изменений согласующий так же должен завершить задачу без выполнения действий согласования, т.к. никаких изменений не вносилось.
Администратор системы должен тоже завершить свою задачу по сохранению базового плана без выполнения действий с проектом.
Только после этого система меняет статус проекта на указанный в запросе инициатором.
В ходе анализа процесса «Управление изменениями» было выявлены следующие недостатки:
1. В рамках исполнения задачи по внесению изменений, доработке внесенных изменений, согласованию запроса на изменение или согласованию внесенных изменений исполнитель не имеет возможности перенаправить задачу другому пользователю, т.к. это не предусмотрено процессом.
2. В число участников процесса входит Администратор системы, выполняющий функцию сохранения базового плана проекта. эту функция целесообразно автоматизировать, т.к. использование человеческих ресурсов влечет дополнительные расходы.
3. В связи с частыми случаями некорректного внесения изменений пользователями необходимо в процесс добавить этап технической экспертизы, который должен стать первым шагом согласования внесенных изменений.
4. При завершении проекта в системе из процесса можно исключить три этапа, которые не представляют значимости для проекта. Это этап внесения изменений, этап согласования внесенных изменений и этап сохранения базового плана. Вместо этого после согласования запроса на изменение статуса проекта система должна изменить статус проекта и завершить процесс.
На рис. 2.5 и рис. 2.6 приведены модели AS IS и TO BE процесса «Управления изменениями» проекта.
Рисунок 2.5 Модель AS IS процесса «Управление изменениями» с выделенными проблемными блоками
Рисунок 2.6 Модель TO BE процесса «Управление изменениями»
Размещено на http://www.Allbest.ru/
2.6 Требования к реализации процессов управления объектами в ИС УГП
В результате анализа действующих в ИАС УП процессов управления проектами с учетом рекомендаций были разработаны требования к реализации следующих процессов в Системе управления государственными программами:
· Разработка/доработка и согласование объекта управления.
· Исполнение объекта управления.
· Внесение изменений в объект управления.
2.6.1 Требования к реализации процесса «Разработка/доработка и согласование объекта управления»
Процесс разработки/доработки и согласования объекта управления (далее - процесс) предназначен для внесения и согласования данных объекта управления.
Процесс состоит из следующих этапов:
1. Создание заявки на регистрацию объекта управления.
2. Разработка объекта управления.
3. Техническая экспертиза.
4. Согласование объекта управления.
5. Доработка объекта управления (при необходимости).
6. Завершение процесса.
Требования к этапу создания заявки на объект управления
При создании объекта управления любой пользователь должен иметь возможность создать заявку-запрос на создание объекта управления, в которой необходимо указать тип, наименование объекта управления, фамилия, имя и отчество руководителя объекта управления из реестра пользователей ИС УГП. В результате сохранения данной заявки должен создаваться Проект выбранного типа и запускаться процесс разработки объекта управления. Пользователю, указанному руководителем объекта управления должна поступать задача на разработку объекта управления и предоставляться права на его редактирование.
При добавлении новых объектов управления любого типа должна быть реализована возможность заполнения заявки на регистрацию. Заявка должна вызываться из раздела «Реестр объектов» путем нажатия кнопки «Создать». На форме заявки пользователь должен иметь возможность:
· Указать тип создаваемого объекта управления.
· Ввести полное наименование объекта управления.
· Указать руководителя объекта управления из списка пользователей ИС УГП.
В результате сохранения заявки в Системе должен создаваться Проект выбранного типа и в зависимости от его типа применяться сценарий разработки объекта управления.
Если в заявке указан тип объекта управления, предполагающий необходимость прохождения объекта управления через процессы разработки, согласования и утверждения Система должна инициировать процесс разработки объекта управления. Пользователю, указанному руководителем объекта управления должна поступить задача на разработку объекта управления и должны быть предоставлены права на его редактирование.
Требования к этапу разработки объекта управления
При запуске процесса разработки объекта управления необходимо передать данные объекта управления и данные с формы заявки и инициализировать переменные процесса:
· Дата начала равна текущей дате.
· Кем создан: = Инициатор процесса.
· ID объекта - идентификатор объекта управления.
· Исполнитель - пользователь, указанный как Руководитель объекта на форме заявки.
· i :=1 - текущая строка в списке согласующих
Задача на разработку должна поступить Руководителю объекта управления, указанному при заполнении заявки.
При назначении задачи должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.
Так же ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета
При назначении задачи процесса, исполнителю должны быть выданы права на редактирование объекта управления.
Исполнитель задачи по разработке объекта управления должен иметь возможность выполнить задачу самостоятельно, перенаправить или указать, что задача поступила не по назначению.
Если форма исполнения задания выбрана «Перенаправить», то на форме задачи должно появиться (открыться для редактирования) поле для указания пользователя, кому задачу необходимо перенаправить. При перенаправлении задачи процесса переходит и ответственность по ее исполнения на пользователя, которому она была перенаправлена, и дополнительной проверки перенаправившим пользователем не требует. Далее происходит назначение задачи по разработке объекта управления пользователю, указанному при перенаправлении задачи. В поле «Исполнитель» записывается значение выбранного при перенаправлении пользователя.
Если форма исполнения задания выбрана «Поступило не по назначению», то инициатору процесса поступает соответствующая задача с возможностью указать другого исполнителя.
Если форма исполнения задания выбрана «Выполнено», необходимо исполнителю задачи закрыть права на редактирование объекта управления.
Требования к этапу технической экспертизы
После завершения этапа разработки объекта управления должен осуществляться оперативный контроль внесенных данных - техническая экспертиза.
Задача «Подготовить заключение о соответствии техническим требованиям» поступает сотруднику департамента мониторинга Администрации Губернатора Пермского края, для которого в учетных данных определена роль «Техническая экспертиза».
При назначении задачи процесса, исполнителю должны быть выданы права на редактирование объекта управления.
Исполнитель задачи должен иметь возможность перенаправить, согласовать или вернуть на доработку пользователю, который разрабатывал проект.
При назначении задачи должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.
Так же ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета.
Если форма исполнения задания выбрана «Перенаправить», то на форме задачи должно появиться (открыться для редактирования) поле для указания пользователя, кому задачу необходимо перенаправить. Далее происходит назначение задачи по подготовке заключение о соответствии техническим требованиям объекта управления пользователю, указанному при перенаправлении задачи.
Если форма исполнения задания выбрана «Требуется доработка», необходимо пользователю, который выполнил задачу по разработке объекта управления назначить задачу по его доработке.
Если форма исполнения задания выбрана «Согласовано», происходит переход на этап согласования объекта управления.
Требования к этапу согласования объекта управления
Согласование разработанного объекта управления происходит сначала с дополнительными согласующими, затем с обязательными.
Дополнительные согласующие выбираются на странице Участники объекта управления в блоке Соисполнители.
Пользователь должен указать дополнительных согласующих по иерархии (значимости) согласующего с проектной ролью «Соисполнитель». Но согласование должно происходить в обратном порядке, указанном в данном разделе.
После завершения согласования с дополнительными начинается согласование с обязательными согласующими.
Список обязательных согласующих формируется в зависимости от типа разработанного объекта управления и уровня заказчика объекта.
Обязательными согласующими для типов действия «дорожная карта», проект, непроектное мероприятие являются:
Если Заказчиком объекта управления является Губернатор Пермского края:
1. Руководитель органа власти, указанного Ответственным исполнителем (Project.Doer.Head).
2. Руководители органов власти, сфера деятельности которых затрагивается при реализации «дорожной карты», проекта, программы или непроектного мероприятия (соисполнители) (Project.Stakeholder.OrganizationUnit.Head, у которых Project.Stakeholder.ProjectRole = Соисполнитель).
3. Переход на следующую стадию согласования осуществляется только после завершения задач по согласованию всеми руководителями ИОГВ соисполнителей.
4. руководители функционально-целевых/функциональных блоков, сфера деятельности которых затрагивается при реализации «дорожной карты», объекта управления, программы или непроектного мероприятия - руководители ФЦБ, в которые входят органы власти, выбранные соисполнителями. (Project.Stakeholder.OrganizationUnit.Hierarhy.Head, у которых Project.Stakeholder.ProjectRole = Соисполнитель).
5. Переход на следующую стадию согласования осуществляется только после завершения задач по согласованию всеми руководителями ФЦБ соисполнителей
6. Председатель Правительства Пермского края (Project.OrganizationUnit.Head, OrganizationUnitName = Председатель Правительства Пермского края).
7. Руководитель департамента мониторинга Администрации губернатора Пермского края (Project.OrganizationUnit.Head, если OrganizationUnitName = Департамент мониторинга Администрации губернатора Пермского края).
8. Заместитель руководителя Администрации губернатора Пермского края, (Project.OrganizationUnit.Head).
9. Заказчик (Губернатор Пк) (Project.Customer)
Если Заказчиком объекта управления является не Губернатор Пермского края, список обязательных согласующих должен формироваться следующим образом:
1. Руководитель органа власти, указанного Ответственным исполнителем (Project.Doer.Head).
2. Руководитель департамента мониторинга Администрации губернатора Пермского края (Project.OrganizationUnit.Head, если OrganizationUnitName = Департамент мониторинга Администрации губернатора Пермского края).
3. Заместитель руководителя Администрации губернатора Пермского края, (Project.OrganizationUnit.Head).
Обязательным согласующим объект управления с типом «Непроектное мероприятие по привлечению федеральных финансовых средств» является определенный сотрудник департамента мониторинга Администрации Губернатора Пермского края. (OrganizationUnitName=департамент мониторинга Администрации губернатора Пермского края.)
Обязательным согласующим для Подпрограмм государственных программ является руководитель органа власти, указанного Ответственным исполнителем (Project.Doer.Head).
Обязательным согласующим Государственных программ является руководитель департамента мониторинга Администрации губернатора Пермского края (Project.OrganizationUnit.Head, если OrganizationUnitName = Департамент мониторинга Администрации губернатора Пермского края).
Исполнитель задачи согласования объекта управления должен иметь возможность согласовать задачу, вернуть на доработку пользователю, который разрабатывал проект и перенаправить задачу.
При назначении задачи должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.
Так же ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета.
Если форма исполнения задания выбрана «Перенаправить», то на форме задачи должно появиться (открыться для редактирования) поле для указания пользователя, кому задачу необходимо перенаправить. Далее происходит назначение задачи по согласованию объекта управления пользователю, указанному при перенаправлении задачи.
Если форма исполнения задания выбрана «Согласовано», происходит проверка по списку согласования, если согласовавший пользователь не последний в списке, задача по согласованию объекта управления назначается следующему в списке.
Этап согласования объекта управления длится до тех пор, пока количество согласовавших (со статусом «Согласовано») не будет равно количеству согласующих в списке.
Если форма исполнения задания выбрана «Требуется доработка», необходимо пользователю, который выполнил задачу по разработке объекта управления назначить задачу по его доработке.
Требования к этапу доработки объекта управления
После назначения задачи на доработку объекта управления, Исполнителю необходимо выдать права на его редактирование.
При назначении задачи на доработку объекта управления должно формироваться уведомление о назначении задачи по шаблону и отправляться на электронную почту исполнителю задачи. Для этого необходимо определять данные исполнителя задачи - фамилия, имя и отчество, аккаунт или логин, e-mail.
Так же ссылка на назначенную задачу должна отобразиться в разделе «Мои задачи» Личного кабинета.
Исполнитель задачи на доработку объекта управления должен иметь возможность выполнить задачу самостоятельно, перенаправить или делегировать задачу.
Перенаправление задачи происходит аналогично с разработкой объекта управления.
Если форма исполнения задания выбрана «Выполнено» происходит переход на этап согласования объекта управления. Задача назначается первому согласующему в списке согласования.
После завершения этапа согласования объекта управления (согласовали все пользователи из списка согласующих со статусом «Согласовано») процесс переходит на этап завершения.
Требования к этапу завершения процесса разработки/доработки и согласования объекта управления
На этапе завершения процесса Система должна выполнить следующие операции:
1. Присвоить значение Project.Status: = Исполнение.
2. Присвоить значение Project.Stage: = Исполнение.
3. Сохранить базовый план объекта - для каждого экземпляра Task:
3.1 Значение атрибута BaseStart принимает значение, равное PlannedStart.
3.2 Значение атрибута BaseFinish принимает значение, равное PlannedFinish.
3.3 Значение атрибута BaseDuration принимает значение, равное PlannedDuration.
Далее процесс разработки/доработки и согласования объекта управления завершается и объект переходит на стадию реализации.
Схема исполняемой модели процесса разработки объекта управления приведена в Приложении В.
Требования к реализации процесса «Отчетность по исполнению»
В рамках обеспечения отчетности по исполнению в раздел «Мои вехи» Личного кабинета должен содержать перечень вех, на которые авторизованный пользователь назначен исполнителем. Вехи, имеющие фактическое окончание в данный список попадать не должны.
В момент формирования отчетности Система должна автоматически формировать список обязательных согласующих, которым в рамках процесса будут назначаться задачи по согласованию фактических данных. Список обязательных согласующих должен формироваться следующим образом:
1. Сотрудник департамента мониторинга Администрации губернатора Пермского края, курирующий реализацию объекта управления - Project.Doer.Куратор.
4 Руководитель ИОГВ-ответственного исполнителя - 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.
Далее должно сформироваться и быть отправлено уведомление Инициатору о завершении процесса согласования отчетности по исполнению и его результатах.
Схема процесса приведена в Приложении Д.
Требования к реализации процесса «Внесение изменений в проект»
Процесс внесения изменений в проект (далее - процесс) предназначен для согласования и внесения изменений в проекты.
Процесс состоит из следующих этапов:
1. Инициация процесса изменения.
5 Согласование запроса на изменение.
6 Доработка (в случае необходимости) запроса на изменение.
7 Внесение изменений.
8 Согласование внесенных изменений.
9 Доработка (в случае необходимости) внесенных изменений.
10 Завершение процесса изменения
Требования к этапу инициации процесса внесения изменений в проект.
Инициировать процесс внесения изменений может пользователь, входящий в рабочую группу объекта управления (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 = департамент мониторинга Администрации губернатора Пермского края.)
Подобные документы
Автоматизация ряда бизнес-процессов библиотеки Арбитражного суда Пермского края с использованием технологии "клиент-сервер". Проектирование пользовательского интерфейса, диаграммы прецедентов. Разработка серверной части, создание и заполнение БД.
курсовая работа [2,9 M], добавлен 27.02.2016Моделирование бизнес-процессов как средство поиска путей оптимизации деятельности компании. Методология SADT (структурный анализ и проектирование), семейство стандартов IDEF и алгоритмические языки в основе методологий моделирования бизнес-процессов.
реферат [21,7 K], добавлен 14.12.2011Администрация Бодайбинского городского поселения как объект исследования, ее структура и направления деятельности. Описание унифицированного языка моделирования UML, разработка бизнес-процессов в его диаграммах. Описание и главные функции GRM-систем.
курсовая работа [1,1 M], добавлен 02.06.2015Анализ деятельности компании в целом и отдела продаж в частности. Описание состояния информационной системы предприятия. Декомпозиция бизнес-процессов, протекающих в отделе продаж. Проектирование информационной системы, ее программное обеспечение.
дипломная работа [2,4 M], добавлен 29.08.2014Создание модели бизнес-процессов "Распродажа" в ВPwin. Цели и правила распродажи. Прогнозирование бизнес-процессов ППП "Statistica". Методы анализа, моделирования, прогноза деятельности в предметной области "Распродажа", изучение ППП VIP Enterprise.
курсовая работа [2,4 M], добавлен 18.02.2012Современное состояние создание отчетов на предприятиях. Обоснование создания системы. Анализ предметной области, системный и структурный анализ. Существующие формы отчетности в УВО. Разработка инфологической и концептуальной схемы БД.
дипломная работа [70,4 K], добавлен 19.06.2006Анализ организационной структуры и деятельности предприятия. Разработка диаграмм бизнес-процессов AS-IS, TO-BE. Характеристика этапов пакетов работ для внедрения автоматизированной информационной системы. Определение состава участников проекта и их задач.
курсовая работа [3,3 M], добавлен 21.01.2015Архитектура интегрированных информационных систем ARIS как методология моделирования бизнес-процессов, преимущества и недостатки использования. Выбор бизнес-процесса для моделирования и его содержательное описание, табличный формат его описания.
курсовая работа [2,2 M], добавлен 19.06.2015Сущность, значение и методика проведения моделирования бизнес-процессов. История развития методологий моделирования. Систематизация знаний о компании и ее бизнес-процессах в наглядной графической форме для аналитической обработки полученной информации.
реферат [409,3 K], добавлен 29.04.2009Информационной обеспечение и информатизация бизнес-процессов предприятия ОАО "Управляющая компания крупнопанельное домостроение". Анализ оснащенности организации вычислительной техникой, программным обеспечением. Состояние информационной безопасности.
отчет по практике [712,3 K], добавлен 18.01.2014