Файл: Разработка Устава проекта (Теоретические аспекты управления командой проекта).pdf

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

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

1.2 Процесс разработки устава проекта

Устав проекта является важным документом проекта. В нем отражена цель проекта и необходимые ресурсы для выполнения проекта. Как правило, проект считается открытым именно после утверждения устава проекта. Поэтому процесс разработки устава проекта крайне важен для успешной реализации проекта. В организации назначается ответственный за разработку устава проекта и сотрудники из заинтересованных подразделений^[7]. Устав проекта утверждает руководитель организации. Большинство методологий, включая PMI PMBoK, сходятся на том, что работы, связанные с подготовкой устава проекта, не должны включаться в проект и выполняются за рамками проекта.

Устав проекта устанавливает партнерство между исполняющей организацией и организацией-заказчиком.

Менеджер проекта определяется или назначается сразу, как только это становится возможным, предпочтительно во время разработки устава проекта и обязательно до начала планирования. Устав проекта наделяет руководителя проекта полномочиями в отношении планирования и исполнения проекта.

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

Рассмотрим рис. 2 процесс «Разработка устава проекта» подробнее. На рисунке ниже изображены входы, инструменты и методы и выходы этого процесса.

Рисунок 2. Разработка устава проекта^[8]

1.2.1 Входы процесса разработки устава проекта

Описание работ проекта — это словесное описание продуктов, услуг или результатов, которые должен произвести проект. Для внутренних проектов инициатор или спонсор проекта предоставляет описание работ на основании бизнес-потребностей, требований к продукту или услуге^[9]. Для внешних проектов описание работ может быть получено от заказчика как часть документации по предложениям или как часть договора. Описание работ проекта отражает:

1. Бизнес-потребность. Бизнес-потребность организации может быть основана на рыночном спросе, технологическом прогрессе, правовых требованиях, постановлениях правительства или соображениях, касающихся защиты окружающей среды. Обычно бизнес-потребность и сравнительный анализ затрат и выгод включены в бизнес-кейс для обоснования проекта;
2. Описание содержания продукта. Описание содержания продукта включает характеристики продукта, услуги или результатов, для создания которых предпринимается проект. Описание должно также отражать взаимосвязь между создаваемыми продуктами, услугами или результатами и бизнес-потребностью, которую должен удовлетворить проект;
3. Стратегический план включает стратегическое видение, цели и задачи организации, а также высокоуровневое описание миссии. Все проекты должны соответствовать стратегическому плану организации. Соответствие стратегическому плану позволяет каждому проекту способствовать общим целям организации.
4. Бизнес-кейс или подобный документ предоставляет необходимую с точки зрения бизнеса информацию, позволяющую определить, стоит ли проект требуемых инвестиций. Он обычно используется вышестоящими по отношению к проекту руководителями для принятия решений. Как правило, в бизнес-кейсе содержится бизнес-потребность и сравнительный анализ затрат и выгод для обоснования проекта и определения его границ, и обычно подобный анализ выполняет бизнес-аналитик, используя различную информацию, полученную от заинтересованных сторон. Спонсор должен согласовать содержание и ограничения бизнес-кейса. Бизнес-кейс создается как результат действия одного или нескольких из следующих факторов:
5. Требование рынка (например, автомобилестроительная компания авторизует проект по изготовлению более экономичных автомобилей в ответ на дефицит бензина);
6. Потребность организации (например, в связи с высокими накладными расходами компания может объединить функции персонала и оптимизировать процессы для сокращения затрат);
7. Требование заказчика (например, электрическая компания авторизует проект по строительству новой подстанции для электроснабжения нового промышленного района);
8. Технологический прогресс (например, авиакомпания авторизует новый проект по разработке электронных билетов для замещения билетов, отпечатанных на бумаге, основываясь на технологических достижениях);
9. Юридическое требование (например, производитель красок авторизует проект для разработки руководящих указаний по обращению с токсичными материалами);
10. Экологические воздействия (например, компания авторизует проект для уменьшения своего воздействия на окружающую среду);
11. Социальная потребность (например, неправительственная организация в развивающейся стране авторизует проект по предоставлению систем питьевого водоснабжения, туалетов и санитарного просвещения сообществам, страдающим от высокого уровня случаев заболеваний холерой).
12. Соглашения используются для определения первоначальных намерений в отношении проекта. Соглашения могут принимать форму договора, меморандума о взаимопонимании, соглашения об уровне услуг, письма-соглашения, письма о намерениях, устных договоренностей, электронного сообщения или других письменных соглашений. Обычно договор используется, если проект выполняется для внешнего заказчика.
13. Факторы среды предприятия, которые могут оказывать влияние на процесс разработки устава проекта, включают в себя, среди прочего:
14. Организационную культуру, структуру и руководство;
15. Географическое распределение оборудования и ресурсов;
16. Государственные и промышленные стандарты (например, предписания контролирующих органов, кодексы поведения, стандарты на продукцию, стандарты качества, стандарты изготовления);
17. Инфраструктуру (например, существующие сооружения и основное оборудование);
18. Имеющиеся человеческие ресурсы (например, навыки, знания, специализации, такие как проектирование, разработка, юридические вопросы, заключение договоров и закупки);
19. Управление персоналом (например, руководящие указания по приему на работу и увольнению, анализ эффективности и результативности работы и записи об обучении персонала, политика вознаграждений и сверхурочной работы, а также учет рабочего времени);
20. Корпоративная система авторизации работ;
21. Ситуация на рынке;
22. Толерантность к риску заинтересованных сторон;
23. Политический климат;
24. Каналы коммуникаций, принятые в организации;
25. Коммерческие базы данных (например, стандартизированные сметные данные, данные изучения промышленных рисков и базы данных рисков);
26. Информационная система управления проектами (например, автоматизированные системы, такие как программное обеспечение для управления расписанием, система управления конфигурацией, система сбора и распределения информации или веб-интерфейсы к другим автоматизированным системам, работающим в режиме онлайн);
27. Государственные и промышленные стандарты или предписания (например, кодексы поведения, стандарты качества или стандарты по защите трудящихся);
28. Организационную культуру и структуру;
29. Ситуацию на рынке.
30. Активы процессов организации, которые могут оказывать влияние на процесс разработки устава проекта, включают в себя, среди прочего:
31. Стандартные процессы организации, политики и описания процессов;
32. Шаблоны (например, шаблон устава проекта);
33. Историческую информацию и базу накопленных знаний (например, проекты, записи и документы, всю информацию и документацию по закрытию проекта, информацию о результатах решений по отбору предыдущих проектов наряду с информацией об исполнении предыдущих проектов, а также информацию об операциях по управлению рисками).

1.2.2 Инструменты и методы процесса разработки устава проекта

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

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

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

1.2.3 Выходы из процесса разработки устава проекта

Устав проекта - документ, выпускаемый инициатором, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта^[10].

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

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

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

Глава 2. Анализ управления командой проекта на примере Банка Рассвет

2.1. Краткая характеристика проекта

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

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

Описание текущей ситуации.

В настоящее время в части мониторинга операций физических лиц на предмет выявления мошеннической активности в Банке используется система антифрод-мониторинга операций, совершаемых с использованием карт WAY4 Real Time Risk Management (RTRM).

Область использования RTRM:

• операции с использованием карт БР;
• операции с использованием карт банков-партнеров;
• операции с использованием терминалов БР;
• операции в ДБО БР.

При этом RTRM – система, основанная на анализе только транзакционных данных в разрезе карты/POS-терминала, имеет ряд серьезных ограничений для эффективного предотвращения мошенничества.

Недостаточность существующей системы мониторинга.

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

2. Отсутствие возможности профилирования клиента.

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

3. Ограничение в быстродействии процессинговой системы.

Правила и расчеты влияют на время обработки авторизаций в процессинговой системе.

4. Отсутствие case-management и ограниченные настройки интерфейса.

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

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

6. Ограниченность алгоритмов.

7. Написание своей собственной логики не предусмотрено

Как результат:

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

- ложные срабатывания систем при ограниченности данных;

- необходимость внедрений на каждое решение: в настоящее время модуль RTRM-эмиссия, RTRM-эквайринг. Необходим отдельный модуль под E-commerce, отдельная система для неплатежной активности в ДБО, для анализа аутентификации по 3D-Secure;

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

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

Цель проекта и критерии ее выполнения представлена в (табл. 2).