Масштабы проекта отражает клиентская база малого бизнеса ВТБ24 — это более 380 000 расчетных счетов и присутствие в 306 городах России. Внедрение шло поэтапно в течение двух с половиной лет, и уже сейчас мы получили значимые конкурентные преимущества. Время вывода продуктов (timetomarket) на рынок — крайне важный фактор. Очевидно, что банки-лидеры движутся в одном направлении, но даже небольшое опережение позволяет предлагать сервис другого уровня. К примеру, в старой системе время вывода продукта составляло 6−8 месяцев. Сейчас это принципиально иная скорость — от месяца до двух. Существенно сократилось время обработки клиентских операций: межфилиальные расчеты раньше проходили в течение часа, сейчас — за 1 минуту. Дополнительно расширено для клиентов предложение по пакетному расчетно-кассовому обслуживанию.
Старая система задавала определенные рамки. Теперь нет ограничений, можно создавать любые комбинации, удовлетворяя все потребности клиентов. Кроме того, автоматизация бизнес-процессов позволила сократить издержки банка. Целый ряд «ручных» операций бэк-офиса теперь проходят автоматически. Банк обеспечиваем прирост клиентской базы на 18−20% в год, без оптимизации процессов потребовалось бы дополнительно нанять 150 человек до конца года.
Ярким примером результатов внедрения платформы ЦФТ является сокращение операционного времени на обработку депозитов в 8 раз, сопровождение гарантий — в 4,5 раза, сопровождение картотеки — в 2 раза. Сбербанк активно применяет новейшие технологии для создания инновационных сервисов и услуг. В частности, методы работы с BigData использованы в разработке универсальной чат-платформы для мессенджеровTelegram и Facebook. Проведен пилот системы биометрической идентификации на основе сетчатки глаза для устройств самообслуживания. При запуске проекта «Оплата по биометрии» в торговой сети «Азбука вкуса» было проведено закрытое тестирование для сотрудников Сбербанка по отпечатку пальца. Реализован пилот по разработке математической модели управления инкассацией и наличностью в устройствах самообслуживания Сбербанка, который призван сократить простой устройств и сэкономить на оптимизации хранимых объемов наличных средств. Успешно завершена начатая 4,5 года назад Программа «Автоматизация систем управления рисками на финансовых рынках». Созданы системы для контроля лимитов рыночного и кредитного рисков, установления лимитов на финансовые институты. Внедрены системы контроля рыночности и независимой верификации цен.
Уникальность этой ИТ-программы для России в том, что до сих пор не было положительного опыта решения аналогичных задач. В итоге при создании риск-инфраструктуры было сэкономлено около 360 млн рублей. Сбербанк внедрил автоматизированную систему мониторинга кредитных заявок для выявления мошеннических действий со стороны корпоративных клиентов. Система обрабатывает большие массивы данных In-Memory, что позволяет производить проверки в режиме реального времени. Сбербанк автоматизировал систему контроля качества андеррайтинга. Запланированное до конца 2017 года создание инструментария анализа рисков позволит улучшить качество кредитного портфеля и обеспечить поддержание высокого уровня экспертизы. Успешно завершен пилот по развертыванию международного карточного процессингового центра. Первым клиентом стал «БПС-Сбербанк» Республики Беларусь. Сбербанк ввел систему, автоматизирующую сбор просроченной задолженности на этапе позднего сбора, в том числе с использованием мобильного приложения коллектора. Сбербанк предложил клиентам «Личный кабинет инвестора», который дал им доступ к просмотру остатков по брокерским счетам, маржинальным показателям, реестру сделок, информации по вводу/выводу денежных средств, движению ценных бумаг между счетами клиента. База данных СМС-сервиса «Мобильный банк» переведена на новый высокопроизводительный ресурс для выдерживания нагрузки в 18 млн входящих СМС от клиентов в сутки.
2016 год был непростым как для банков, так и для компаний-интеграторов. Для первых — потому что они должны были решать задачу дальнейшей автоматизации своих бизнес-процессов. Для компаний-интеграторов — потому что перед ними стояла задача помогать своим партнерам из числа банков, предлагая им эффективные решения. Глава 3. РАЗРАБОТКА И ВНЕДРЕНИЕ ПРОЕКТА СПЕЦИАЛИЗИРОВАННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПО СИСТЕМЕ AGILE ВПАО БАНК «ОТКРЫТИЕ"3.1 Характеристика и окружение проектавнедрения бизнес портала открытия счета в ПАО Банк «Открытие"Банк «Открытие» — крупнейший частный банк в России и четвертый по размеру активов среди всех российских банковских групп1. Работает на финансовом рынке с 1993 года. Активы банка и его дочерних компаний по МСФО на 30 июня 2016 года составили 3 087,8 млрд рублей, собственный капитал — 217,8 млрд рублей. «Открытие» — универсальный коммерческий банк с устойчивой диверсифицированной структурой бизнеса и качественным управлением капиталом. Банк развивает следующие ключевые направления бизнеса: корпоративный, инвестиционный, розничный, МСБ и PrivateBanking. Особое внимание «Открытие» уделяет высокотехнологичным сервисам: в рамках проекта «Рокетбанк» предлагается полностью дистанционный сервис для физических лиц, в рамках проекта «Точка» — полностью дистанционное обслуживание для предпринимателей. Банк «Открытие» был сформирован в результате интеграции более чем 10 банков различного масштаба, в том числе таких крупных федеральных, как НОМОС-БАНК, Ханты-Мансийский банк и банк «Петрокоммерц».Банк «Открытие» входит в список десяти системообразующих кредитных организаций, утвержденный Центральным банком, а также в список крупнейших компаний мира FORBES Global 2000.
Надежность банка подтверждена рейтингами международных агентств S&P Global (ВВ-) и Moody’sInvestorsService (Ba3).Клиентская база объединенного банка насчитывает свыше 30 000 корпоративных клиентов, 165 000 клиентов малого бизнеса и около 3,2 млнфизических лиц, в том числе премиальных клиентов. 470 отделений банка различного формата расположены в 53 экономически значимых регионах России. Значительная часть бизнеса сосредоточена в Москве, Санкт-Петербурге, Тюменской области (включая Ханты-Мансийский автономный округ, где банк работает под брендом Ханты-Мансийского банка, узнаваемость которого на данной территории исторически высока), Екатеринбурге, Новосибирской области, Хабаровском крае, Волгоградской области. Ключевым акционером банка «Открытие» является «Открытие Холдинг», который владеет 66,64% голосующих акций. Бенефициарами «Открытие Холдинг» являются: Вадим Беляев, Группа «ИФД Капиталъ», Банк «ВТБ», Группа «ИСТ», Рубен Аганбегян, Александр Мамут. Бумаги банка также находятся в свободном обращении на Московской бирже. Банк «Открытие» внедрил новый проект — бизнес портал открытия счета (.
https://www.open.ru/business_portal). Это диджитл канал открытия счета. Клиент вводит информацию в специальную форму на сайте и банк ему открывает счёт. Каждый клиент автоматически проверяется банком во внешних источниках, чек листах банка. Тем самым оптимизируется работу сотрудников подразделений банка: фронт офис, мидл офис, риск подразделений, отдел открытия счётов. Весь процесс полностью автоматизирован. Подобный опыт открытия счета был вРоссельхозбанке. Однако, там был стандартный водопад, работа полностью бумажная, вся информация вводиласьв ручную, заявки переводятся в ручную. Время на Открытие счета в Россельхозбанке более 5 дней. Изначально проект стал работать по аджаилу. Вся информация обрабатывается и исправляется моментально благодаря аджаилу. Вначале проекта была команда из 15 человек, сейчас уже более 70. Открывая счёт в «Открытии», клиент получает:
Резервирование номера счётаОткрытие счёта в рубляхПодключение интернет-банкаВыезд менеджера для открытия счётаЗаверение документовУведомление госорганов об открытии счёта.
Достоинства интернет-банка для малого бизнеса:
Реквизиты нового счета за 1 минутуПереводы средств с СМС подтверждениемПерсональный менеджерБез посещения офиса банкаОбновление остатка и ленты в реальном времениЛегко посмотреть детали операций, повторить или отозвать платеж, создать шаблон и получить выпискуСчета доступны 24/7 и 365 дней в году.
Недостатки интернет-банка для малого бизнеса:
Отсутствие четких инструкций/подсказок для некоторых их запрашиваемых документов (например, действие в случае договора аренды, налоговой декларации) и действий (например, как загрузить паспорт);
— Отсутствие анимации при обработке системой определенного действия; возникает ощущение зависания системы;
— Банк запрашивает очень много информации о клиенте;
— Неудобные календарь и тарифный калькулятор. Оперативная связь с банком является достоинством. Однако, в связи клиентов с банков есть и свои недостатки:
Ограничение по количеству вложенийНет «Корзины», нет предупреждения при удалении писем, — Нет возможности сохранения письма в «Черновиках"Преимущества digital для клиентов банка:
быстрый дистанционный доступ к банковским продуктам (резервирование и реквизиты счета — 1мин., он-лайн размещение депозит, оперативное управление лентой платежей) — бизнес «под ключ»: банковский сервис, партнерские продукты (юридические, бухгалтерские, налоговые и т. д.) — получение высококачественного сервиса не выходя из дома. Преимущества для банка:
сокращение издержек на поддержание большой сети;
— автоматизация сложных процессов/сквозное обслуживание, — обеспечение высококачественного сервиса — длительные отношения клиента с банком,-формирование дополнительной комиссионной стоимости за счет небанковских продуктов.
3.2 Ключевые участники и заинтересованные стороны проекта бизнес портала открытия счета в ПАО Банк «Открытие».Заказчик внедрения и разработки ПО — в ПАО Банк «Открытие».Исполнитель — поставщик программного обеспечения для финансового рынка. План проекта по внедрению бизнес портала открытия счета составлялся на основании традиционной модели жизненного цикла проектов, т. е. в виде «водопада» — последовательные фазы, где каждая фаза не может начатьсябез завершения предыдущей. Дата начала проекта — 23мая 2016 г. План проекта, а также распределение ресурсов построены были в программе MicrosoftOfficeProject (рис.
3.1)Рис.
3.1. План проекта по внедрению ПО в ПАО Банк «Открытие"Соответствующая плану диаграмма Ганта (т.е. визуализированная цепь задач) показана на рис.
3.2Рис.
3.2 Диаграмма Ганта проекта.
Как видно из рис.
3.2, проект менеджером был спланирован как «водопад», этапы сформулированы достаточно широко. В плане проекта нет операций слияния и дробящихся операций. После того, как командой проекта и менеджером проекта начатовнедрение.
ПО, оказалось, что сроки исполнения задач сдвигаются, причем вслед за той задачей, которая выполняется с продлением базового срока, сдвигается выполнение последующих задач. При реализации проекта фиксировалась длительность каждой задачи, после этогопостроен был календарный реальный план. Сравнение фактических и запланированных сроков выполнения проекта при выполнения работ показано на рис.
3.3. Среди 14-ти задач 9 имели отклонения по длительности: задачи № 3, № 4, № 5, № 6, № 7, № 8, № 10, № 11, № 12. Рис.
3.3. Отклонения фактического плана от базового.
Для наглядности данных отклонений построена диаграмма Ганта с отслеживанием, где задачи базового плана выделены серым, а задачи реального плана — синим (рис.
3.4.). Даже по данному рисунку видно, что длительность проекта превышает запланированную. Это же дает основания считать, что и стоимость проекта увеличилась.Рис.
3.4 Диаграмма Ганта с отслеживанием.
При помощи наблюдения за процессом выполнения проекта были систематизированы и выявлены причины задержек задач проекта:
Задача 3 «Сбор требований, документирование стратегии принятия решений». Базовая длительность -35 дней, фактическая — 46 дней. Эта задача — один из основных этапов проекта, где оформлялось техническое задание на спецификацию правил настройки рисковой стратегии. На этом этапе со стороны исполнителя участвовали основной разработчик истарший аналитик. — Долгое формирование требований, стремление к снижению рисков методом полной аналитики разногласий в будущем. Как последствие — задержка подписания технического задания заказчиком (Банком);
— В рисковую политику вносились добавления икорректировки, а как последствие, в требования кПО;
— Неопределенность операционного отдела в предоставлении требований аналитикам по работе ПО;
— С Банка за задержки дополнительная плата не взималась, т.к. на тот момент техническое задание было не подписано (оно стало итогомэтого этапа).Задача 4 «Проектирование модели данных на основании кредитной политики»: Базовая длительность — 3 дня, фактическая — 14 дней. Отдел маркетинга в предыдущем этапе не принимал участия в формировании требований кПО, однако на текущем его представители внеслисвои пожелания по работе ПО с клиентом. Данные изменения в требованиях, по мнению исполнителя, ТЗ в некоторых местах противоречили, поэтому за доработку данных требований Банку пришлось заплатить 79 200 руб. Задача 6 «Проектирование общей логики архитектуры решения»: Базовая длительность — 6 дней, фактическая — 12 дней. Задержки на данном этапе связаны с коммуникацией между исполнителем и организациями, предоставляющие дополнительные сервисы (ЦФТ, CreditRegistry).Задача 8 «Разработка схемы XSD модели данных»: Базовая длительность — 2 дня, фактическая — 8 дней. Разработчику на этом этапе пришлось поменять первоначальную модель данных, т.к.отдел маркетинга и операционный отдел Банка потребовали новый функционал, который необходим им для работы с клиентами (т.е. возможность отсылать заявки клиентов на предыдущий этап). Банку запрос на изменение стоил 24 000 руб. Задача 9 «Разработка тест-стенда для проверки корректности реализованной стратегии»: Базовая длительность — 37 дней, фактическая — 41 день. Тест-стенд на вход получает XML-сообщение, потом обращается к серверу, в котором находится ПОпо принятию решения о выдаче кредита, и потом на экранепоявляется новое, дополненное XML-сообщение с итогами проверки. Тест-стенд в первом релизе функционала сохранения XML-ответов не имел, что Банку показалось неудобным. Проблема задержки на этом этапе вызвана различным толкованием ТЗ работниками банка иразработчиками. Исполнитель утверждал, что задача корректно выполнена, по крайней мерев ТЗ предмет спора описан не был, а Банк считал что этот пункт не нужно подробно описывать. Исполнитель дополнительные работы оценил в 32 000 руб. Задача № 10 «Программирование стратегий во внедренной ИС»: Базовая длительность — 33 дня, фактическая — 54 дня. Задержки на этом этапе связаны с изменениями требований.
ПО, которые вызваны корректировками отдела рисков, операционного отдела иотдела маркетинга. Многие нововведенияпривели к изменениям в модели данных. Банку запросы на изменения обошлись в 84 000 руб. Задача № 11 «Модульное тестирование разработанной стратегии»: Базовая длительность — 6 дней, фактическая — 19 дней. С итогами тестирования ознакомлены были работники отдела рисков Банка. Задержки при выполненииэтой задачи вызваны расхождением между работниками отдела рисков и разработчиками программы по поводу корректности стратегии. Заказчикустановил новые требования, которые учитывают динамику заявки клиентов во времени (данный функционал в ТЗ был неописан). Трудозатраты на добавление этого функционала менеджером были оценены проекта в 32 ч., в денежном выражении — 16 000 руб.
по ставке разработчика. Задача № 12: «Интеграционное тестирование ИС с фронт-офисным решением»: Базовая длительность — 10 дней, фактическая — 20 дней.
Поскольку на этом этапе в качестве человеческого ресурса применяется специалист по интеграции, то понятно, что в работе он руководствуется только ТЗ, которое создано задолго до данного этапа аналитиками и подписано банком. Субъективная трактовка многих пунктов ТЗ приводит к интеграционной реализации, не удовлетворяющей Банк. Разногласия, в основном, связаны были с количеством и качеством отображаемых данных на экране (отображение обязательств и доходов клиента, подсчет рисковых показателей, итоги проверки его кредитных историй, скоринговый балл, итоги пробивки по черным спискам);
— Внедряемое ПО рассчитываетриск-сегмент клиента, рисковые показатели, проверяет соответствие правилам политики банка. Описанные действия предполагают комментарии, которые в ТЗ и требованиях записаны на русском языке. Реализация их осуществлена была на этапе программирования стратегии, но на этапе интеграции с фронт-офисным решением выяснилось, что передача данных возможна лишь при помощи латинского алфавита; следовательно, разработчикам для решения этой проблемы пришлось вводить понятие «транслитерации». Было потрачено время на обсуждение проблемы между менеджером проекта иБанком. Таким образом, издержки по водопадной модели, которые понес Банк на этом этапе, превысили ожидаемые.
3.3 Разработка плана подготовки и реализации проекта.
Проанализировав недостатки водопадной модели при ее применении для управления IT-проектами в банке, а также преимущества «гибких» методологий разработки и выбрав методологию «скрам» как более подходящую методологию для управления IT-проектом из-за ее организованности иформализации, смоделирована ситуация внедрения ПОдля принятия решений о выдаче кредита с применением методологии «скрам».Скрам-мастер фокусируется на процессе разработки и является наставником своей команды. Основные обязанности скрам-мастера следующие:
Поддержание ритма и устранение помехУправление процессом СкрамПланирование релизаПланирование спринтовЗащита команды от внешних воздействийСодействие проведению скрам-митинговОбеспечение четких и прозрачных коммуникаций между всеми заинтересованными в проекте сторонами.
Скрам-мастер, как правило, является лидером команды. Скрам-мастер в идеале должен иметь баланс между следующими навыками:
Техническая экспертизаПонимание намерений продукт-оунераХороший командный игрок и наставникПонимание возможностей командыХороший мотиваторРешение проблем.
Всего в Scrum используется 4 базовых процесса:
Планирование спринтаЕжедневный скрам-митингДемо спринтаРетроспектива.
Начнем с процесса планирования спринта, а в других статьях рассмотрим остальные процессы. В Scrum используется итерационная модель жизненного цикла проекта, а итерации называются спринтами, т.к. они достаточно короткие во времени — от одной до четырех недель. Конкретную продолжительность спринта выбирает команда проекта. Как правило, команда пробует работать со спринтами разной продолжительности, а затем выбирает ту продолжительность, которая ей удобна, и до конца проекта ее не меняет. Не менять длительность спринтов — очень важно, т.к. команда привыкает работать с одним и тем же темпом и выдавать результат по окончании каждого спринта. Итак, у команды есть журнал продукта. В этом журнале владелец продукта каждый день наводит порядок: добавляет новые истории, расставляет приоритеты по ним, а команда может помогать ему в этой работе. При планировании спринта команда должна на себя взять столько обязательств по выполнению историй из журнала продукта, сколько она может реально реализовать за один спринт. Для того, чтобы спланировать спринт команде нужно знать:
Объем работ по каждой истории, которую команда собирается реализовать в спринтеСкорость командыКоличество часов, которое есть у команды на спринт.
Также для того, чтобы правильно спланировать спринт, а именно, не набрать на себя слишком много работы, команды должна знать свою скорость. Об измерении скорости я уже писал в одной из своих статей. И третья важная вещь при планировании спринта — это понимание того, сколько часов есть у команды на спринт. На практике при расчете этого значения наша команда рассчитывала, сколько часов каждый участник команды может работать в следующем спринте, а затем мы суммировали эти часы и умножали на значение усредненного Focusfactor предыдущих спринтов. Таким образом, итогом планирования спринта становится журнал спринта. (рис.
3.5.). План проекта строился при помощи дополнения кПОMicrosoftOfficeProject 2010, называемоеScrumTool, которое помогает процесс просто формализовать.Рис.
3.5. Моделирование первого спринта.
Как видно из рисунка, на протяжении1-го спринта задействованы были специалист по интеграции, два аналитика итри разработчика. Они детализировали требования журнала спринта, а также оценили время, требующееся им для выполнения задания. С учетом изменений в требованиях, описанных при рассмотрении плана проекта, который построен при помощи водопадной модели, смоделирован итоговый журнал продукта (т.е. после завершения проекта) (рис.
3.6)Рис.
3.6. Журнала продукта в конце проекта.
Как видно из рисунков, кроме названия требования-задачи в журнал так же пишутся степень приоритета, статус требования-задачи ираспределение в спринты. Журнал продукта — требования заказчика, которые написаны понятным ему языком. Подробное описание требований уменьшает риск отклонения от желаемого Банком качества. Полноценный смоделированный проект показан на рис.
3.7. Рис.
3.7. Представление проекта внедрения ПО в банк при помощи «скрам».
— методологии.
ЗАКЛЮЧЕНИЕ
Все больше компаний берет на вооружение методы управления гибкими проектными командами, которые позволяют в сжатые сроки выводить на рынок продукты более высокого качества. Гибкий подход — это планирование и составление графика методом набегающей волны. Под методом набегающей волны принято понимать принцип планирования, характеризующийся последовательной разработкой графика проекта, при котором любая задача планируется с глубокой детализацией иерархической разбивки работ. Работы же, которые планируются на далекое будущее, планируются с малым раскрытием; по мере решения далеко стоящих задач часть их, которая требует исполнения в ближайшее время, подвергается полному раскрытию. Поэтому результат реализовываемого проекта неизвестен, так как весь процесс состоит из постоянных повторений во время его реализации. Каждое повторение — это небольшой «бокс» продолжительностью 1−4 недели. Целью каждого этапа является разработка функционального продукта, отвечающего ряду требований, для предоставления его заказчику или инвестору. В конце каждого «бокса» меняются приоритеты и направленность работ для подгонки существующих характеристик под те, которые требуются заказчиком или инвестором. После внесения поправок и распределения задач между членами проектной команды начинается новый этап. Каждый следующий этап всегда обусловлен выпуском продукта с расширенным функционалом. Повторяющиеся процессы дают ряд преимуществ:
Непрерывный контроль над характеристиками продукта, его проверка и утверждение.
Частая демонстрация результатов завершенного этапа повышает вероятность удовлетворения клиента при окончательной сдаче проекта.
Возможность выявление дефектов на ранней стадии и оперативное принятие мер к корректировке.
Гибкое планирование превосходит планирование традиционное, особенно когда нужно поставить на рынок новые товары. Стоит отметить, что гибкое управление проектами — это не один метод, а совокупность методов, способная оперативно реагировать на вызовы непредсказуемых проектов. Среди самых популярных методов гибкой реализации надо выделить: Scrum («схватка»), экстремальное программирование (XP), гибкое моделирование, бережливое развитие, RUP (рациональные и единообразный процесс), кристальная ясность, метод развития динамических систем, быстрая разработка продукции (RPD).Проект «Бизнес портал» успешно внедрен в банке и находится в промышленной эксплуатации. Благодаря методике скрам, проект успешно внедрен небольшими доработками, а именно, бэк лог команды разбит на итерации. Могу смело отметить, успешный рол аут на регионы пилотным был город Москва. Далее мы расшились на весь центральный регион, на сегодня смело идем в Поволжье. За период жизни проекта в течении года мы разработали функционал с банковскими услугами банка ПАО ФК Открытие, но на проекте планируем расширять как клиентские сервисы, так и банковские. Сегодня клиенты банка могут открыть счет полностью диджитл каналом, без посещения офиса банка. Клиент получает реквизиты счета в течении 1 минуты.
Благодаря нашим доработкам мы как команда ввели новые для себя понятия в работе, команда полностью кросфункциональна и технически подкована. Нам удается разработать E2E процессы за короткий срок, благодаря нашей методике мы пытаемся быть клиент ориентированными на рынок, так же пытаемся быть успешными по технологиям, так как в настоящее время современные диджитл каналы развиваются очень быстро. СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫАфонин, А. М. Управление проектами: Учебное пособие / А. М. Афонин, Ю. Н. Царегородцев, С. А. Петрова. — М.: Форум, 2010. ;
184 c. Аганбегян А. Г. Еще раз о новой роли банков в современных условиях // Деньги и кредит. — 2011. — № 12. ;
С.3−8.Балашов, А. И. Управление проектами: Учебник и практикум для СПО / А. И. Балашов, Е. М. Рогова, М. В. Тихонова и др. — Люберцы: Юрайт, 2016. — 383 c. Балашов, А. И. Управление проектами: Учебник и практикум для академического бакалавриата / А. И. Балашов, Е. М. Рогова, М. В. Тихонова и др. ;
Люберцы: Юрайт, 2016. — 383 c. Богданов В. Управление проектами. Корпоративная система — шаг за шагом. -.
М.: Манн, Иванов и Фербер, 2012. — 248 с. Брукс Фредерик. Мифический человеко-месяц, или как создаются программные системы. — М, Символ-плюс, 2010.
— 304 с. Банковское дело / под ред. О. И. Лаврушина. М.: Финансы и статистика, 2012. ;
672 с. Беляков A.B. Банковские риски: проблемы учета, управления и регулирования. — М.: Издательская группа «БДЦ-пресс», 2012. ;
256 с. Богданова О. М. Коммерческие банки России: формирование условий устойчивого развития. — М.: Финстатинформ, 2008. — 212 с. Буевич С. Ю., Королёв О. Г. Анализ финансовых результатов банковской деятельности. ;
М.: КНОРУС, 2012. — 160 с. Буздалин A.B. Секреты дистанционного анализа банка // Бизнес и банки. — 2012. — № 36(722).- С. 42−45Вольфсон Б.
Гибкие методологии разработки, версия 1.2 (электронная книга), 2012.
Грей, Клиффорд Ф. Управление проектами: учебник: пер. с англ. третьего, полн. перераб. изд./ Клиффорд Ф. Грей, Эрик У. Ларсон; [науч.Ред. перевода В.
М. Дудников]. — М.: Издательство «Дело и Сервис», 2007. — 608 с.
— Доп. тит. л. англ. Грекул В. И., Коровкина Н. Л., Куприянов Ю. В.
Методические основы управления ИТ-проектами. — Интернет-университет информационных технологий, 2011. -.
392 с. Гробовцов Г. Я. УПРАВЛЕНИЕ ПРОЕКТОМ: Учебно-методический комплекс. — М.: Изд. центр
ЕАОИ, 2009. — 288 c. Голикова Е. Электронные платежные системы: правовые основы и учет // Финансы и закон. — 2011. — № 15.
— С.74−84.Горбунов К. Н. Банки и компании телекоммуникации: новые продукты, новые возможности // ЭКО. — 2011. — №.
8. — С.89−103.Дитхелм Г. Управление проектами. В 2 т. Т. I. пер. снем. -.
СПБ.: Издательский дом «Бизнес-пресса», 2004. — 400 с. Дитхелм Г. Управление проектами. В 2 т. Т. II. пер. снем. -.
СПБ.: Издательский дом «Бизнес-пресса», 2004. — 288 с. Джалота, П. Управление проектами в области информационных технологий / П. Джалота. — М.: Лори, 2014. ;
224 c. Деятельность коммерческих банков: Учебное пособие/ под ред. проф., д.э.н. А. В. Калтырина — Ростов-на-Дону: «Феникс», 2012. — 384 с. Евсеенко А. В. Электронные деньги в борьбе с коррупцией и теневой экономикой в крупном городе / А. В. Евсеенко, К. В. Огрызько // ЭКО. — 2011.
— № 8. — С.76−88.Зуб, А. Т. Управление проектами: Учебник и практикум для академическогобакалавриата / А. Т. Зуб. — Люберцы: Юрайт, 2016.
— 422 c. Йордон, Э. Управление сложными Интернет-проектами / Э. Йордон.
— М.: Лори, 2014. — 344 c. Кметь Е. Развитие электронных платежных систем // Пробл. теории и практики управл. ;
2011. — № 4. — С.116−126.Кондрашов В. А. Тенденции развития банковских инноваций в современной России // Российское предпринимательство. ;
2012. — № 8 (206). — С. 101−105.Колодкина М. В. Электронные денежные средства как объект гражданских правоотношений // Рос.юстиция. — 2011.
— № 12. — С.8−9.Курасов А. П. Роль и значение внедрения новых технологий платежной системы банка России / А. П. Курасов, К. И. Попов, Т. О. Махначева // Деньги и кредит. ;
2010. — № 10. — С.23−28.Мазур И. И., Шапиро В. Д., Ольдерогге Н.
Г. Управление проектами: Учебное пособие / Под общ.
ред. И. И. Мазура. — 2-е изд. — М.: Омега-Л, 2004. — с. 664Портни, Стэнли И.
Управление проектами для «чайников».: Пер. с англ. — М.: Издательский дом «Вилямс», 2005. — 352 с.: ил. -.
Парал. тит. англ. Полищук А. И. Основные типы банковских рисков // Финансы и кредит. — 2008. — № 25.
— С. 20−31.Разу М. А., Бронникова Т. М., Разу Б. М., Титов С. А., Якутин Ю. В.
Управление проектом. Основы проектного управления: учебник / кол. авт: под ред. проф. М. А. Разу.
— М.: КНОРУС, 2006 — 768 с. Солдатов, В. П. Управление программными проектами / В. П. Солдатов. — М.: Бином, 2010. ;
384 c. Сооляттэ, А. Ю. Управление проектами в компании: методология, технологии, практика: Учебник / А. Ю. Сооляттэ. — М.: МФПУ Синергия, 2012. — 816 c. Соснин, Э. А. Управление инновационными проектами: Учебное пособие / Э. А. Соснин. ;
Рн/Д: Феникс, 2013. — 202 c. Товб А. С., Ципес Г. Л. Управление проектами: стандарты, методы, опыт. — М.: ЗАО «Олимп-Бизнес», 2003.
— 240 с.: ил. Грекул В. Проектирование информационных систем (лекции), 2010.
Черных Е. А. AgileProjectManagement и его история, М., «Менеджмент качества», 02(02)2008.
Топ-7 методов управления проектами: Agile, Scrum, Kanban, PRINCE2 и другие[Электронный ресурс] Режим доступа:
http://www.pmservices.ru/project-management-news/top-7-metodov-upravleniya-proektami-agile-scrum-kanban-prince2-i-drugie/Методы управления проектами: ScrumvsKanban [Электронный ресурс] Режим доступа:
http://suhorukov.com/news_akademy/metody-upravleniya-proektami-scrum-vs-kanbanAgile методология: принципы и правила применения [Электронный ресурс] Режим доступа:
https://www.kom-dir.ru/article/1910;agile-metodologiyaСекреты эффективности работы в команде: какие методы лучше и проще использовать [Электронный ресурс] Режим доступа:
https://rovertask.com/ru/blog/management/agileСущность рынка банковских услуг в Зарубежных странах [Электронный ресурс] Режим доступа:
https://studwood.ru/571 640/bankovskoe_delo/suschnost_rynka_bankovskih_uslug_zarubezhnyh_stranahМеждународный опыт развития сектора банковских услуг [Электронный ресурс] Режим доступа:
https://www.kazedu.kz/referat/125 920/2Лучшие ИТ-партнеры для банков [Электронный ресурс] Режим доступа:
http://nbj.ru/publs/upgrade-modernizatsija-i-razvitie/2016/12/19/luchshie-it-partneery-dlja-bankov/46.Самые значимые ИТи ИБ-проекты 2016 года [Электронный ресурс] Режим доступа:
http://www.jetinfo.ru/stati/samye-znachimye-it-i-ib-proekty-2017;goda.
