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

Содержание:

Введение

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

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

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

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

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

В проекте под названием «Отпуск», заявление на отпуск является уставом проекта. Здесь присутствует и цель — «отпуск» и сроки — «от и до» и даже бюджет.

В российской практике данный документ чаще называется Концепция проекта. Концепция (от лат. conceptio — понимание, система), определённый способ понимания, трактовки какого-либо предмета, явления, процесса, основная точка зрения на предмет и др., руководящая идея для их систематического освещения. Задачи Устава проекта — сформировать единое представление о проекте у всех участников и формализовать достигнутые договоренности. Устав проекта может быть, как внутренним документом, так и документом, согласуемым с внешними сторонами проекта, фактически выполняя роль контракта между заказчиком и исполнителем. Последний подход чаще используется зарубежом.

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

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

Целью работы ‑ является разработка устав проекта.

Задачей проекта:

1. Изучить понятие проекта, его сущность и признаки.
2. Изучить процесс разработки устава проекта.
3. Изучить краткую характеристику проекта.
4. Изучить состав устава проекта.

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

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

Глава 1. Теоретические аспекты управления командой проекта

1.1. Понятие проекта: сущность и признаки

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

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

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

2. Временной горизонт действия. Каждый проект ограничивается во времени.

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

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

5. Системное функционирование проекта, элементный состав. Между элементами проекта является взаимосвязь. Однако состав проекта не всегда остается неизменным: некоторые элементы могут возникать или теряться.

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

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

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

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

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

Жизненный цикл проекта - промежуток времени между моментом появления, зарождения проекта и моментом его ликвидации, завершения^[4].

Жизненный цикл проекта показывает:

• какие работы будут выполнены в установленном промежутке времени;
• в какой этап каждой фазы будут достигнуты результаты;
• кто участник в каждой фазе;
• как проводить контроль и подтверждать каждую фазу;

При помощи жизненного цикла проекта можно выявить;

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

Фазы жизненного цикла проекта - цепь логически объединенных операций проекта, оканчивающихся достижением одного или более поставляемых результатов. Фазы проекта применяются, когда направление выполняемой задачи уникально для части проекта, и связаны с созданием ключевого поставляемого результата. Фаза выделяет процессы из конкретной группы процессов управления проектом, но большая часть или даже все процессы будут исполняться в какой-либо форме. Фазы проекта в основном исполняются по порядку, но бывают такие проектные ситуации, когда и перекрываются. Различные фазы, обычно, имеют разную протяженность. Высокоуровневый характер фаз проекта обозначает их частью цикла проекта^[5].

Фазы жизненного цикла проект:

• фаза 1 - концептуальная фаза – формулирование целей и задач;
• фаза 2 - фаза планирования – заранее намеченный порядок, комплекс заданий;
• фаза 3 - фаза реализации проекта – реализация проекта с контролем хода его выполнения;
• · фаза 4 - фаза завершения проекта – мероприятия, направленные на завершения проекта.

На рис. 1показаны фазы жизненного проекта.

Рисунок 1. Фазы жизненного цикла проекта^[6]

Рассмотрим содержание каждой фазы проекта:

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

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

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).

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

В (табл.3), которая указана ниже представлены риски проекта.

Таблица 1

Подразделения Банка^[11]

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

Таблица 2

Цель проекта и критерии выполнения^[12]

Цель	Критерии выполнения
Предотвращение мошенничества, в котором используются несколько каналов (например, ДБО и карты). Покрыть системой антифрод весь спектр каналов проведения операций с использованием платежных средств физических лиц.	Внедрение системы IBM Counter Fraud Management for Safer Payments.

Таблица 3

Риски проекта^[13]

Описание риска и его влияние на проект/цели проекта	Неоптимальное внедрение системы сотрудниками банка.
Влияние на проект (задачи, план, бюджет)	Задачи
Степень влияния (низкая/средняя/высокая)	Высокая
Вероятность (низкая/средняя/высокая)	Низкая
Мероприятия по управлению риском	Очное обучение сотрудников Банка на площадке IBM. Заключение договора с IBM на оказание консультационных услуг в ходе внедрения.

В данной таблице указываются риски, выявленные на этапе пред проектными работами. Риск - это событие или условие (как внешнее, так и внутреннее), которое может повлиять на результаты и достижение целей проекта.

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

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

Процессы.

• Онлайн-авторизация.
• Клиринг;
• Функционирование ДБО/ACS/MPI;
• Блокировка/разблокировка карты/токена/терминала/пользователя ДБО.

Каналы по способу обслуживания:

• Эмиссия карт Банка;
• Эмиссия банков-партнеров;
• Эквайринг;
• ДБО физических лиц (интернет-банк, мобильный-банк);
• E-Commerce.

Регионы/Банки Группы Рассвета.

• Филиальная сеть Банка Рассвет;
• Банки-партнеры на обслуживании в процессинге Банка Рассвет;
• Банки-партнеры на межхостовом взаимодействии (в рамках транзакционной активности, обрабатываемой процессингом Банка).

Исключения из проекта (ограничения)

В рамках проекта НЕ планируется решение следующих задач:

• Перевод на мультиканальную систему антифрода ДБО юридических лиц и AML-мониторинга.

Требования к проекту.

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

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

2. Система будет высоконагруженной, работать по схеме 24/7, т.е. быстродействие и безотказность, важные параметры новой системы антифрода.

3. Работа системы антифрода ведется в режиме реального времени.

4. Различные каналы, по которым могут осуществляться распоряжений по управлению денежными средствами. К таким каналам относятся:

• Мобильные приложения, установленные на смартфонах и планшетах;
• Классические WEB-приложения;
• Специальные клиентские места Клиентов (АРМ Клиента);
• Посещение офиса Банка, подача распоряжений на бумажные носители;
• Инфраструктура платежных карт.

5. Оперативное реагировать на возникнувшие инциденты.

Ограничения нескладывающиеся на проект

1. Временной фактор. Проект не может выполняться неограниченное время.

2. Бюджет проекта.

3. Привлекаемые сотрудники. Сотрудники не могут заниматься только этим проектом. Этапы и сроки проекта.

В данном разделе указываются основные проектные этапы и их вехи из плана. В (табл.4) представлены этапы проекта.

Таблица 4

Этапы и сроки^[14]

Работа	Пункт плана	Предшествующие этапы	Длительность	Дата начала	Дата окончания
A	Обследование, анализ, выбор поставщика	-	8	28.03.18	06.04.18
B	Заключение договора на проектирование с OpenWay	A	1	09.04.18	12.04.18
C	Проектирование интеграционного решения с OpenWay	B	5	13.04.18	19.04.18
D	Заключение договора на обучение с IBM	C	2	20.04.18	23.04.18
E	Заключение договора на проектирование с Solanteq	D	1	24.04.18	24.04.18
F	Обучение сотрудников Банка	E	6	25.04.18	02.05.18
G	Проектирование интеграционного решения с Solanteq	F	27	03.05.18	08.06.18
H	Заключение договора на интеграцию с Solanteq	G	4	11.06.18	14.06.18
I	Составление рабочего плана интеграции	H	1	15.06.18	15.06.18
J	Установка интеграционного решения Solanteq	I	6	18.06.18	25.06.18
K	Первое тестирование	J	11	26.06.18	10.07.18
L	Второе тестирование	K	4	11.07.18	16.07.18
M	Третье тестирование	L	8	17.07.18	26.07.18
N	Четвёртое тестирование	M	6	27.07.18	03.08.18
O	Пятое тестирование	N	23	06.08.18	05.09.18
P	Пилотная эксплуатация Safer Payments	O	3	06.09.18	10.09.18
Q	Запуск Safer Payments в промышленную эксплуатацию	P	12	11.09.18	26.09.18
R	Запуск канала On-Us в промышленную эксплуатацию	Q	10	27.09.18	10.10.18
S	Запуск канала ДБО в промышленную эксплуатацию	R	26	11.10.18	15.11.18
T	Запуск канала ACS/MPI в промышленную эксплуатацию	S	65	16.11.18	14.02.19

Иерархическая структура проекта приведена на рис. 3 который указан ниже.

Рисунок 3. Иерархическая структура работы проекта ^[15]

На рис. 4 представлена сетевая модель вида Работа – Вершина, которая показывает последовательности выполнения работ.

Рисунок 4.Сетевая модель вида Работа–Вершина^[16]

На рис 5 показана сетевая модель вида Работа – Дуга. Из схемы видно, что все этапы идут друг за другом без параллельно выполняемых этапов.

Рисунок 5.Сетевая модель вида Работа-Дуга^[17]

Календарный план проекта приведен на рис. 6.

Рисунок 6. Календарный план данного проекта (часть1)^[18]

Продолжение календарного плана проекта рис. 7.

Рисунок 7. Календарный план данного проекта (часть 2)^[19]

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

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

1) Структура управления.

На рис. 8 приставлена организационная структура проекта команды управления проектом.

Рисунок 8. Организационная структура проекта^[20]

2) Заказчик проекта Начальник Департамента платежных средств.

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

Общая информация по проектной команде отражена в (табл. 5).

Таблица 5

Проектная команда^[21]

Подразделение	Процент занятости на проекте	Временной период участия в проекте (название этапа проекта, или календарные сроки)	Область ответственности
	50%	Весь срок проекта	Замещает менеджера проекта по всем вопросам
ДПС	20%	Весь срок проекта	Контроль над проектом
	30%	Весь срок проекта	Интеграция ПО с процессингом
ДПБС	10%	Весь срок проекта	Системная интеграция ПО
УРЭБ	10%	Весь срок проекта	Интеграция ПО с системами нового ДБО
УИБ	5%	Весь срок проекта	Соблюдение требований ИБ
ДЭА	5%	Весь срок проекта	Соблюдение требований безопасности, согласование фродовой модели

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

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

2.2. Состав устава проекта

Обобщенная информация по уставу проекта модификации системы антифрода приведена в (табл.6).

Таблица 6

Общая информация об уставе проекта^[22]

Наименование проекта	Построение мультиканальной системы фрод-мониторинга на базе IBMCounterFraudManagementforSaferPayments
Заказчик проекта	Начальник Департамента платежных средств Исаев Д.М
Менеджер проекта	Начальник Отдела рисков и претензионной работы ДПС Субботин И.А
Дата старта проекта	28/03/2018
Дата завершения проекта	14/02/2019
Бюджет	55 600 000 рублей

История релизов проекта представлена в (табл.7).

Таблица 7

История обновление устава проекта системы антифрода^[23]

Дата	Версия	Изменения	Исполнитель
28/03/2018	0.1	Создание документа	Исаев Д.М
28/11/2018	0.2	Корректировка по результатам 23.07.2018	Субботин А.А
16/12/2018	0.3	Корректировка по результатам 15.11.2018	Петров А.А
01/01/2019	0.4	Корректировка по результатам 26.12.2018	Орлов И.И

Таблица 8

Бюджет проекта ^[24]

	Сумма	Валюта	Сумма в рублях	Бюджетная заявка
CAPEX
Лицензия IBM Counter Fraud Managements for Safer Payments	299 995,00	USD	17 613 341,00	14479
IBM - Обучение сотрудников Банка	2 006 000,00	RUR	2 006 000,00	20079
IBM - Консультационные услуги (200 часов)	4677610,00	RUR	4 677 610,00	20107
Аппаратное обеспечение	8 700 000,00	RUR	8 700 000,00	20106
SOLAR Switch (Опция: платежные системы – VISA, МС, МИР, UPI, НСПК)	3 000 000,00	RUR	3 000 000,00	20107
SOLAR Bridge (Инрефейс с внешней системой фрод-мониторинга)	3 500 000,00	RUR	3 500 000,00	20079
SOLAR Frаud Prevention (Опция: ACS/MPI Monitoring)	1 000 000,00	RUR	1 000 000,00	20107
OPEX
OpenWay - Проектирование интеграционного решения	35 400,00	EUR	2 478 000,00	20105
SOLANTEQ - Проектирование интеграционного решения	1 250 000,00	RUR	1 250 000,00	20105
SOLANTEQ - Услуги по внедрению	4 100 000,00	RUR	4 100 000,00	20105
IBM - Поддержка продукта	4 000 000,00	RUR	4 000 000,00	20068
Найм сотрудников
Администратор системы - ДИТ (руб/мес)
Специалист поддержки - ДПС (руб/мес)			3 200 000,00
Специалист разработки - ДПС (руб/мес)
	ИТОГО:		55 524 951,00

В (табл.8) которая указана выше, представлен бюджет по проекту модификации системы антифрода.

Т.к. бюджетные заявки утверждались под первоначальный подход к внедрению (OpenWay – интеграция, IBM – внедрение), соответствие бюджетных заявок дано ориентировочно. В ходе проекта, бюджетные заявки будут скорректированы под утвержденный 27.03.18 бюджет проекта и подход к внедрению (Solanteq – интеграция, Банк – внедрение).

Шаблон листа согласования представлен в (табл.9).

Таблица 9

Лист согласование устава проекта^[25]

Согласовано	Ф.И.О.	Дата согласования	Подпись
Заказчик проекта	Исаев Д.М	26.03.18	Исаев Д.М
Руководители ДСП	Субботин А.А	26.03.18	Субботин А.А
Руководитель ДЭА	Петров А.А	26.03.18	Петров А.А
Менеджер проекта	Субботин И.А	26.03.18	Субботин И.А
Руководитель ДПБС	Иванов А.А	26.03.18	Иванов А.А
Руководитель УРЭБ	Смирнов И.А	26.03.18	Смирнов И.А
Руководитель УИБ	Орлов И.И	26.03.18	Орлов И.И

В главе 2 разработан проект для Банка. Создан устав проекта по модификации системы антифрода. Выделены этапы проекта такие как:

• подписание договора;
• уточнение технического задания;
• риски проекта;
• примерный макет решения проекта;
• тестирование и опытное внедрение;
• опытно-промышленная эксплуатация.
• Сорок реализации данного проекта 1 год.

Заключение

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

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

Показаны основные фазы жизненного цикла проекта.

В работе приведено обоснование необходимости модификации существующей си.

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

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

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

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

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

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

Содержание устава проекта зависит от специфики поставленной задачи. В качестве примера можно привести следующий набор разделов устава.

• Начальные условия – что привело к инициации проекта, входные условия.
• Цели и ожидания проекта – чего мы хотим достичь на выходе.
• Содержание и результаты – что именно включается в состав проекта, какие конкретные результаты будут получены. Например, если нужно модифицировать систему антифрода, то на выходе должны иметь саму систему, сервера, на которых она будет поставлена, обученных пользователей и документацию для передачи в поддержку.
• Ключевые требования и характеристики – то, что не является результатом проекта, но важно для него. Если опять вернуться к системе антифрода, то таким требованием будет "Срок обучения сотрудника системе не должен превышать 1 месяца" и т.д.
• Бюджет и сроки – деньги, сроки и их взаимоотношения с другими сторонами, участвующими в реализации проекта.
• Ключевые участники – основные заинтересованные лица.

Список Литературы

1. Афонин, А. М. Управление проектами / А.М. Афонин, Ю.Н. Царегородцев, С.А. Петрова. - М.: Форум, 2016. – 184с.
2. Борщевский, Г. А. Государственно-частное партнерство. Учебник и практикум / Г.А. Борщевский. - М.: Юрайт, 2015. - 346 c.
3. Кемп, Сид Управление проектами. Без мистики / Сид Кемп. - М.: Гиппо, 2014. - 372 c.
4. Проекты и управление проектами в современной компании: учебное пособие / Товб А.С., Ципес ГЛ.- М.: Олимп-Бизнес, 2010. - 304с.
5. Управление проектами: Практическое руководство / Грей К.Ф.,

Ларсон Э.У. – М.: Дело и сервис, 2003. - 521с.

1. ГОСТ Р 54869-2011 Проектный менеджмент требования к управлению проектом. – 2011. - Режим доступа: -http://docs.cntd.ru/document/gost-r-54869-2011
2. ГОСТ Р 54870-2011 Проектный менеджмент. Требования к управлению портфелем проектов. – 2011. - Режим доступа: http://docs.cntd.ru/document/gost-r-54870-2011
3. ГОСТ Р 54871-2011 Проектный менеджмент. Требования к управлению программой. – 2011. - Режим доступа: http://docs.cntd.ru/document/1200089606

1. Афонин, А. М. Управление проектами / А.М. Афонин, Ю.Н. Царегородцев, С.А. Петрова. - М.: Форум, 2016.- c. 11. ↑

2. Кемп, Сид Управление проектами. Без мистики / Сид Кемп. - М.: Гиппо, 2014. - с. 13. ↑

3. Проекты и управление проектами в современной компании: учебное пособие / Товб А.С., Ципес ГЛ.- М.: Олимп-Бизнес, 2010. - с.14 ↑

4. Кемп, Сид Управление проектами. Без мистики / Сид Кемп. - М.: Гиппо, 2014. - с. 14. ↑

5. Афонин, А. М. Управление проектами / А.М. Афонин, Ю.Н. Царегородцев, С.А. Петрова.М.: Форум, 2016. - c. 15. ↑

6. Борщевский, Г. А. Государственно-частное партнерство. Учебник и практикум / Г.А. Борщевский. - М.: Юрайт, 2015. – с.50. ↑

7. Проекты и управление проектами в современной компании: учебное пособие / Товб А.С., Ципес ГЛ.- М.: Олимп-Бизнес, 2010. - с. 20.

   ↑

8. Борщевский, Г. А. Государственно-частное партнерство. Учебник и практикум / Г.А. Борщевский. - М.: Юрайт, 2015. – с.40. ↑

9. Афонин, А. М. Управление проектами / А.М. Афонин, Ю.Н. Царегородцев, С.А. Петрова. - М.: Форум, 2016. - c .25. ↑

10. Управление проектами: Практическое руководство / Грей К.Ф.,

    Ларсон Э.У. – М.: Дело и сервис, 2003. - с.14. ↑

11. Таблица сделана по данным заказчика. ↑

12. Таблица сделана по данным заказчика. ↑

13. Таблица сделана по данным заказчика. ↑

14. Таблица сделана по данным заказчика. ↑

15. Иерархическая структура работ построена в MS Visio. ↑

16. Сетевая модель составлена по данным таблицы 4 в программе MS Visio. ↑

17. Сетевая модель составлена по данным таблицы 4 в программе MS Visio. ↑

18. Календарный план сделан в программе MSProject. ↑

19. Календарный план сделан в программе MSProject. ↑

20. Организационная структура сделана в MS Visio. ↑

21. Таблица сделана по данным заказчика. ↑

22. Таблица сделана по данным заказчика. ↑

23. Таблица сделана по данным заказчика. ↑

24. Таблица сделана по данным заказчика. ↑

25. Таблица сделана по данным заказчика. ↑