Управление проектами в банковской сфере
Понятие, характеристика и особенности управления IT-проектом. Построение модели жизненного цикла в банковской сфере. Обоснование методологии "скрам" для моделирования процессов менеджмента в банке. Выбор специализированного программного обеспечения.
| Рубрика | Банковское, биржевое дело и страхование |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 27.04.2016 |
| Размер файла | 4,0 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://allbest.ru
Оглавление
Введение
Глава I. Характеристики и особенности управления IT-проектом
1.1 Определение проекта
1.2 Понятие управления проектами и команда проекта
1.3 Управление IT проектом
1.3.1 Определение IT проекта и его особенности
1.3.2 Модели жизненного цикла IT проекта: их характеристики и особенности
1.4 Постановка проблемы
1.4.1 Специфика банковской сферы
1.4.2 Анализ применимости моделей жизненного цикла в банковской сфере
Глава II. «Гибкие» методологии управления IT-проектами
2.1 Описание и принципы «гибких» методологий управления IT-проектами
2.2 Обоснование выбора методологии «скрам» для моделирования процесса управления IT-проектом
2.3 Описание методологии «скрам»
Глава III. Управление проектом внедрения специализированного программного обеспечения в Банк
3.1 Характеристика внедряемого программного обеспечения в Банк
3.2 Управление проектом внедрения ПО на основе водопадной модели
3.3 Моделирование и анализ внедрения проекта с помощью «гибкой» методологии «скрам»
Заключение
Список использованной литературы
Введение
Управление проектами сегодня отличается от управления проектами в 1950-х, когда эта наука стала впервые применяться строительными и инженерными копаниями в качестве инструмента для эффективной организации новой деятельности. Сейчас управление проектами используется практически во всех областях, так как это позволяет поддерживать экономическую активность организаций.
С развитием информационных технологий многим компаниям стало очевидно, что, используя различные автоматизированные информационные системы, можно повысить рентабельность бизнеса. Особенно это стало актуально для российских банков, так как они пытаются повысить свою конкурентоспособность на рынке с помощью использования специализированных программных систем, ориентированных на банковскую деятельность. Таким образом, с повышением степени вовлеченности IT-продуктов в жизнь общества, тема об эффективном управлении IT-проектами стала очень популярной.
В данной дипломной работе управление IT-проектом будет рассматриваться в банковской сфере, которая считается довольно уязвимой из-за сильной коррелированности с внешней средой и экономикой страны. Ввиду этих специфик, а также характеристик IT-проекта, управление внедрением или созданием ПО в банках сталкивается с множеством трудностей, такими как сдвиги по срокам, ненадлежащее качество, превышение по запланированной стоимости и тому подобное. Ненадлежащее качество продукта, являющегося результатом управления какого-либо IT-проекта в банке, может сильно сказаться на дальнейшей экономической активности этого банка.
Во многих российских банках жизненный цикл IT-проектов рассматривается с точки зрения традиционной водопадной модели (то есть в виде модели, где каждый последующий этап процесса начинается только тогда, когда завершится предыдущий), применение которой основано, скорее, на привычке менеджеров проектов, нежели на реальной эффективности модели. В последнее время большую популярность приобретают «гибкие» методологии управления IT-проектами, основная суть которых базируется на преимуществах итеративной и спиральной моделей жизненного цикла. Помимо этого, «гибкие» методологии пропагандируются как «готовые к изменениям», что в большинстве случаев больше подходит для IT-проектов, управляемых в быстро меняющихся средах. Этим объясняется актуальность выбранной темы для исследования.
Объектом исследования является IT-проект по внедрению программного обеспечения в банк. Предметом исследования являются способы управления IT-проектом, основанные на том или ином представлении жизненного цикла этого IT-проекта (модели и методологии).
Таким образом, целью данной работы является выявление целесообразности применения «гибкой» методологии «скрам» для управления IT-проектом вместо традиционного «водопадного» на примере IT-проекта по внедрению специализированного программного обеспечения для автоматизированной оценки кредитоспособности клиента и для принятия решения о выдаче кредита в Банк «XXX». Критерием оценки целесообразности является реализация проекта на заданном уровне качества при значительно меньшем уровне затрат и времени.
В рамках поставленной цели были определены следующие задачи:
· выявление характеристик проекта и управления проектом;
· определение критериев успешности проекта;
· определение особенностей IT-проекта;
· анализ преимуществ и недостатков моделей жизненного цикла управления IT-проектом;
· определение сущности и преимуществ «гибких» методологий управления IT-проектами;
· анализ различных видов «гибких» методологий и обоснование выбора методологии «скрам» как наиболее подходящей для исследования;
· описание основных моментов, характеристик и особенностей методологии «скрам»;
· реализация проекта по внедрению программного обеспечения в Банк с использованием традиционной водопадной модели жизненного цикла;
· предложение по управлению этим же IT-проектом с использованием «гибкой» методологии «скрам»;
· анализ и сравнение результатов с учетом определенных критериев успешности IT-проекта.
Дипломная работа состоит из трех глав, введения, заключения, списка использованной литературы и приложения.
Первая глава посвящена понятиям «проект», «управление проектом», «IT-проект», «жизненный цикл IT-проекта», а также анализу моделей жизненного цикла IT-проекта. В конце главы рассматриваются характеристики банковской сферы и применимость описанных моделей жизненного цикла в зависимости от этих характеристик.
Во второй главе рассматриваются «гибкие» методологии управления IT-проектами, проводится их сравнительный анализ и выбирается методология «скрам» для моделирования и управления конкретным IT-проектом в практической части.
В третьей главе реализуется проект внедрения специализированного программного обеспечения для автоматизированной оценки кредитоспособности клиента и для принятия решения о выдаче кредита, и моделируется этот же проект с использованием методологии «скрам».
Глава I. Характеристики и особенности управления IT-проектом
1.1 Определение проекта
Термин «проект» берет свои истоки в латинском языке, происходя от слова «projecere» - бросаться вперед. В английском языке слово «project» сохранило базовую суть из латинского языка, сузив, при этом, основное значение - деятельность, направленная на достижение поставленной цели. В современном обществе операционное управление бизнесом, которое нацелено на управление устоявшимися бизнес-процессами, теряет свою актуальность. Это связано в первую очередь с тем, что внешняя среда постоянно претерпевает резкие и существенные изменения, соответственно, большую популярность приобретают проекты, то есть такие активности, которые характеризуются определенной степенью уникальности при решении какой-либо задачи. Помимо всего прочего, у организации может быть множество целей, следовательно, появляется огромное число проектов, разных по своей природе, и от их управления может зависеть будущее всей организации. Для того чтобы какая-либо активность смогла называться проектом, необходимо, чтобы у нее одновременно присутствовали нижеприведенные характеристики:
· Четко-определенная цель (как правило, это получение какого-то конечного результата, удовлетворяющего организацию);
· Установленная продолжительность проекта с ранее определенными датами начала и завершения проекта;
· Предопределенные требования к ресурсам (время, оборудование, финансы и труд);
· Координированное участие различных специалистов в одном проекте (то есть, синтез многочисленных разнонаправленных действий)
В современных книгах все определения термина «проект» базируются на этих характеристиках. Таким образом, предлагаются следующие определения:
Проект - это
1) «комплексное, неповторяющееся, единовременное мероприятие, ограниченное по времени, бюджету, ресурсам, а также четкими указаниями по выполнению, разработанными под потребности заказчика» [4, с. 13];
2) «системный комплекс плановых (финансовых, технологических, организационных и прочих) документов, содержащих комплексно-системную модель действий, направленных на достижение оригинальной цели» [11, с. 21].
Проекту так же свойственна зависимость между четырьмя показателями: бюджет (заданные в плане оценочные затраты на проект), длительность (период времени, необходимый для выполнения проекта), область охвата (цели и задачи проекта) и качество (рисунок 1):
Рис. 1 Треугольник проекта
Изменение одного из этих элементов влияет на три других. Ограниченность бюджета определяется количеством средств, которое было выделено для реализации проекта. Ограниченность длительности определяется временным периодом, в рамках которого проект должен быть реализован. Ограниченность области охвата определяется действиями, которые должны быть выполнены для того, чтобы цель проекта была достигнута. Сбалансированность этих показателей может свидетельствовать об успешности проекта.
1.2 Понятие управления проектами и команда проекта
До XX века проектами управляли непосредственно их создатели, а ими, как правило, являлись архитекторы, инженеры и строители, однако вскоре и другие организации начали осознавать, что грамотное управление проектом является очень важным для их деятельности. Особенно отчетливо это понималось в сферах строительства, консалтинга и обороны. Со временем стало увеличиваться количество людей, стремящихся к познанию в этой области: если несколько лет назад в университетах можно было встретить курсы по управлению проектами, которые читались исключительно для студентов, обучающихся на инженерных специальностях, то сейчас напротив, все больше и больше факультетов включают дисциплину «управление проектами» в свои программы обучения. Таким образом, выпускники факультетов маркетинга, информационных технологий, экономики, финансов, медицины и других наук имеют представление об управлении проектами, что, безусловно, важно в сегодняшние дни, потому что управление проектами охватывает не только сферы бизнеса и строительства, как раньше, но и любые стороны деятельности общества.
В современной литературе термин «управление проектами» подразумевает под собой различные методы, способы и идеи о том, как сделать бизнес более эффективным. В качестве примера ниже приводятся определения, описанные в различных российских и зарубежных источниках:
Управление проектами - это
1) «методология (говорят также -- искусство) организации, планирования, руководства, координации трудовых, финансовых и материально-технических ресурсов на протяжении проектного цикла, направленная на эффективное достижение его целей путем применения современных методов, техники и технологии управления для достижения определенных в проекте результатов по составу и объему работ, стоимости, времени, качеству и удовлетворению участников проекта» [9, с. 18];
2) «область менеджмента, охватывающая те сферы производственной деятельности, в которых создание продукта или услуги реализуется как уникальный комплекс взаимосвязанных целенаправленных мероприятий при определенных требованиях к срокам, бюджету и характеристиками ожидаемого результата» [12, с. 15];
3) «профессиональная деятельность по руководству ресурсами (человеческими и материальными) путем применения методов, средств и управления для успешного достижения заранее поставленных целей в результате выполнения комплекса взаимосвязанных мероприятий при определенных требованиях к срокам, бюджету и характеристикам ожидаемых результатов проектов» [6, с. 7];
4) «особый вид управленческой деятельности, базирующийся на предварительной коллегиальной разработке комплексно-системной модели действий по достижению оригинальной цели и направленный на реализацию этой модели» [11, с. 22].
В рамках управления проектом происходит постоянное взаимодействие участников проекта, к которым относятся инициатор, заказчик, менеджер проекта, инвестор и, непосредственно, команда проекта.
Основная идея проекта устанавливается инициатором. В дальнейшем, ее перенимает заказчик, который заинтересован в определенных результатах проекта. Заказчиком определяются желаемые временные рамки проекта, а также различные требования к проекту. Финансирование проекта осуществляется либо заказчиком, либо инвестором, который может вступать в контрактные отношения с заказчиком. Менеджер проекта занимается управлением деятельностью, направленной на реализацию поставленных целей в рамках проекта. Он несет прямую ответственность за достижение целей и за возможные ошибки перед заказчиком. Под руководством менеджера проекта происходит формирование команды проекта в зависимости от сложности организации проекта и возложенных на команду обязательств. При наборе людей в команду менеджер проекта должен учитывать их профессиональную квалификацию и опыт работы. Таким образом, чем сложнее является проект, тем более квалифицированной должна быть команда.
1.3 Управление IT проектом
1.3.1 Определение IT проекта и его особенности
С развитием информационных технологий одна часть организаций стала автоматизировать свою деятельность, а вторая часть начала создавать программное обеспечение для его дальнейшей поставки организациям первого типа. И в первом и во втором случае, организации имеют дело с IT-проектами.
Термин «IT-проект» можно описать в виде общего термина «проект» но с некоторыми важными дополнениями, связанными, прежде всего, с тем, что IT-проект подразумевает собой деятельность, направленную на создание или использование информационных технологий (Грекул, Коровкина, 2011). Так как в данной работе пойдет речь об управлении проектом внедрения специализированного программного обеспечения (то есть, некой информационной технологии), то целесообразно определить, что именно отличает IT-проект от обычного проекта. Во-первых, диссонанс между заказчиком и исполнителем. Чаще всего IT-проекты заказываются бизнес-отделом организации, а внедряются - собственным IT отделом или самостоятельной IT-компанией (отдаются на аутсорсинг). При таком подходе очевидно, что возможны трудности в определении бизнес-требований и общих ожиданий от разрабатываемого и внедряемого программного обеспечения, так как область IT является довольно специфичной. Это означает, что на первых этапах проводимые обсуждения между заказчиком и исполнителем могут нести в себе достаточно размытые идеи, которые на ранних стадиях фиксируются наспех в техническом задании, а потом меняются. При первичном чтении технического задания у заказчика может возникнуть ряд вопросов, и это нормально, потому что разработчик технического задания мог понять какие-то аспекты IT-проекта очень субъективно. Другой особенностью IT-проекта является равномерное распределение вины на участниках проекта при его неблагополучной реализации. Таким образом, ответственность за результат ложится не только на исполнителя (за возможную неправильную реализацию) или не только на заказчика (за возможную ошибку в формировании требований), а на всех участников вместе, потому что, так или иначе, они должны создавать между собой эффективную коммуникацию, минимизируя возможный субъективизм в дальнейшем. Третьей особенностей IT-проекта можно назвать его высокую стоимость. Если при построении здания возможны лишь минимальные отклонения от конечных требований и ожиданий, то в IT-проектах это весьма вероятно. Соответственно, есть риск внесения существенных изменений, а так как очень часто отношения между заказчиком и исполнителем регулируются ранее подписанным контрактом, то любое изменение влечет за собой так называемый «запрос на изменение», который стоит определенную сумму денег. Большое число изменений подразумевает под собой и большую стоимость, именно поэтому IT-проекты считаются одними из самых дорогих видов проектов.
1.3.2 Модели жизненного цикла IT проекта: их характеристики и особенности
Определение жизненного цикла IT-проекта: Каждый IT-проект проходит путь с момента своего создания через ряд промежуточных этапов и до его завершения, когда информационная технология полностью создана или внедрена. Другими словами можно сказать, что у проекта есть фазы, которые называются общим термином - жизненный цикл. Свод знаний по управлению проектами (PMBoK) дает следующее определение понятию жизненный цикл проекта:
«Жизненный цикл проекта - это набор, как правило, последовательных и иногда перекрывающихся фаз проекта, названия и количество которых определяются потребностями в управлении и контроле организации или организаций, вовлеченных в проект, характером самого проекта и его прикладной областью» [27, с. 15].
Жизненный цикл помогает координировать усилия участников проекта, так как он учитывает некоторую специфику. К примеру, руководитель проекта должен понимать, какое влияние оказывают входы и выходы одного этапа жизненного цикла на остальные. Жизненный цикл проекта имеет прямую связь с его финансированием, так как, только спланировав фазы его реализации, можно прогнозировать стоимость и издержки.
В наиболее общих чертах схема жизненного цикла IT-проекта может быть представлена четырьмя фазами: инициация, планирование, выполнение и закрытие (рисунок 2):
Рис. 2 Схема жизненного цикла IT-проекта
· Инициация: создается идея проекта, определяются бизнес-требования и цели;
· Планирование: составляются план проекта, финансовый план, план качества и план ресурсов; определяется работа, которая должна быть сделана в рамках проекта;
· Выполнение: исполнение задач; полученные результаты оцениваются руководителем проекта и впоследствии сравниваются с планом проекта;
· Закрытие: окончательный результат и сформированная документация представляются заказчику; формируется уровень успеха проекта.
Водопадная модель жизненного цикла IT-проекта: Водопадная модель была введена примерно в 1970 году, и она является традиционным подходом к управлению IT-проектами. Водопадный процесс представляет собой упорядоченную последовательность различных фаз развития проекта, причем каждая фаза имеет набор входов и выходов (Holtsnider, 2010).
Основные фазы водопадной модели жизненного цикла IT-проекта представлены на рисунке 3.
· «Разработка требований». Происходит сбор бизнес-требований заказчика, после чего осуществляется их преобразование в функциональные требования к программному продукту;
· «Архитектура и дизайн». Определение требований, относящихся к программному обеспечению (базы данных, параметры безопасности, модели данных и интерфейсная схема);
· «Разработка». Создание программного продукта, базирующегося на спецификациях, определенных на предыдущих стадиях;
· «Тестирование». Проверка отсутствия в программном продукте каких-либо дефектов, а также соответствия функциональности требованиям заказчика
· «Внедрение». Инсталляция продукта;
· «Поддержка». Проверка корректности в дальнейшей работе программы.(Ledbrook, 2012), (Melonfire, 2006).
Рис. 3 Водопадная модель жизненного цикла IT-проекта
Ключевым моментом водопадной модели является ее последовательный характер, что означает, что каждая фаза не может начаться, если не завершена предыдущая. Данная модель требует четкого планирования в самом начале проекта, и это всегда сопровождается написанием больших технических заданий, а результат работающей программы можно наблюдать только в конце.
Управлением IT-проектом в «водопаде» руководит менеджер проекта, который поручает задания разработчикам и устанавливает сроки и бюджет. На протяжении всего жизненного цикла команда проекта отчитывается по проделанной работе только перед менеджером, коммуникации непосредственно с заказчиком отсутствуют. Если определенные в начале проекта требования не меняются, то руководствоваться техническим заданием весьма целесообразно.
Проблема заключается в том, что на деле ни один IT-проект нереально спроектировать таким образом, чтобы заранее предугадать все требования пользователей, его функционал и так далее. Помимо всего прочего, если что-то было упущено в работе проекта на его начальных стадиях, исправить это, находясь на завершающих этапах, очень сложно и требует дополнительных затрат.
Подводя итог, можно отметить, что преимущества данной модели имеют место только в небольших проектах при четко определенных и неизменяемых требованиях; в других же случаях, скорректированные планы могут способствовать невыполнению проекта.
Итеративная модель жизненного цикла IT-проекта: Итеративная модель жизненного цикла значительно отличается от водопадной. Данный подход подразумевает последовательность циклических итераций, где каждая из них состоит из четырех фаз: сбор требований, планирование, разработка и тестирование (рисунок 4) (Jalote, 2004).
Рис. 4 Фрагмент итерации итеративной модели жизненного цикла IT-проекта
Главной характеристикой итеративной модели является то, что каждая итерация добавляет новый функционал в программный продукт. Для Jalote [32, с. 117] «новая итерация начинается до завершения текущей, тем самым, являясь продолжением актуальной версии программного обеспечения». В этом случае, направление проектной деятельности может быть изменено в начале каждой итерации, что является довольно удобным в случае быстро меняющейся внешней среды.
Функциональность всей системы может быть глобально оценена уже в начале проекта (на первых итерациях), а необходимые второстепенные изменения могут быть сделаны в течение следующих итераций.
Более того, итерации могут служить средством обратной связи для измерения качества выполнения проекта и продуктивности работы команды участников.
Итеративный подход к планированию жизненного цикла предполагает, что различные виды работ над проектом не привязаны к каким-то конкретным стадиям разработки; вместо этого они выполняются по мере необходимости.
Спиральная модель жизненного цикла IT-проекта: Развитием идеи итеративной разработки программного обеспечения является спиральная модель жизненного цикла, предложенная Барри Боэмом в 1986 году. Основной сутью данной модели является минимизация рисков в начале каждой итерации путем повышения коммуникации внутри команды проекта. В начале каждой итерации спиральной модели разработчики идентифицируют:
Ш Цели разрабатываемого в течение данной итерации фрагмента программного обеспечения;
Ш Основные и альтернативы пути к достижению поставленных целей;
Ш Анализ возможных ограничений.
После этого команда проекта начинает идентифицировать проблемы, которые могут возникнуть в течение итерации, а также причины их возникновения (нехватка информации, недостаточная квалификация сотрудников). Далее команда начинает разрабатывать стратегию осуществления проектных работ в рамках данной итерации с учетом обнаруженных рисков.
Каждый «виток спирали» представляет собой законченную часть разрабатываемого, продукта, соответственно, с каждым новым «витком» проект достигает более глубокий уровень детализации и конкретизации (рисунок 5):
Рис. 5 Спиральная модель жизненного цикла IT-проекта
Планированию каждой итерации-«витка» уделяется особое внимание, так как Боэм полагал, что неудачная реализация итераций связана, прежде всего, с низкой коммуникацией специалистов в команде проекта. Одним из явных недостатков спиральной модели является сложность определения момента для перехода на следующую фазу (Грекул, 2010).
С развитием теории управления IT-проектами разработчики и их менеджеры поняли, что объединенный вариант итеративной и спиральной моделей жизненного цикла может стать лучшим способом для организации процесса управления IT-проектом.
Пошаговая разработка и наличие готовых фрагментов работающего ПО, взятые из итеративной модели, а также главенствующая роль человеческого фактора и анализ возможных рисков, взятые из спиральной модели были объединены в новую методологию, получившую название «гибкой» методологии (agile - англ). Под гибкостью подразумевается следующее:
· Возможность быстро реагировать на изменения для того, чтобы преуспеть в беспокойной бизнес-среде;
· Возможность быстрого изменения степени приоритета используемых ресурсов в ответ на изменения в требованиях, технологиях и знаниях;
· Возможность быстрой реакции на любые угрозы рынка, а также на любые изменения, вызванные влиянием заказчиков;
· Использование инкрементального подхода в поставке продукта для максимального удовлетворения требованиям заказчика;
· Максимальное увеличение рентабельности проекта путем стремления завершить все работы в срок.(Cobb, 2011). Ebrary Making Sense of Agile Project Management : Balancing Control and Agility
1.4. Постановка проблемы
1.4.1 Специфика банковской сферы
Сейчас в России насчитывается 939 банков http://www.banki.ru/banks/ratings/?utm_source=google&utm_medium=cpc&utm_campaign=Banki_Rossii, причем довольно велико и количество стартапов. Конкуренция начинает возрастать, и банкам приходится искать новые пути к завоеванию больших объемов рынка. Рынок требует от банков высокой адаптивности к возможным изменениям внешней среды, а адаптивному ведению бизнеса способствуют информационные технологии, поэтому одним из главных показателей успешности банка в настоящий момент является степень его автоматизации.
Идеи об организации автоматизации банковских процессов начали появляться недавно, и это связано с возросшей тенденцией выпускать различные внешние автоматизированные сервисы, предоставляющие определенную информацию о клиентах.
Если взять во внимание рынок кредитования, то в качестве примеров таких сервисов можно, безусловно, привести программный комплекс CreditRegistry, выпущенный компанией ЗАО «МТЦ». CreditRegistry автоматизирует бизнес-процессы, связанные со взаимодействием банка с бюро кредитных историй и другими сервисами, помогающими банку организовать свою работу на рынке потребительского кредитования http://creditregistry.ru/. Развитие таких сервисов стимулирует банки автоматизировать работу внутри своих департаментов, получая значительную часть данных о клиентах извне.
Банковская сфера является одной из быстро меняющихся и рискованных, что имеет прямое влияние на управление проектами в банках. Достаточно вспомнить кризис 2008 года, после которого множество банковских проектов было попросту заморожено.
Банковская сфера также связана с экономической деятельностью государства, соответственно, любые изменения в экономике страны способны изменить актуальность каких-либо данных, использующихся в банках.
Таким образом, те IT-проекты, которые предназначаются для автоматизации именно специфических банковских функций, с большей вероятностью будут подвержены изменениям из-за изменений окружающей среды в течение периода их реализации.
Банкам также характерны многочисленные конфликты между департаментами, и это зависит от различий в видениях бизнеса. К примеру, рассматриваемый в данной работе проект по внедрению программного обеспечения по принятию решения о выдаче кредита является синтезом идей трех банковских департаментов: рисков, операционного отдела и отдела продаж и маркетинга.
Каждый департамент формирует требования, отсортированные по приоритету, руководствуясь собственными мотивами: для отдела продаж главным является повышение количества выданных кредитов (что способствует дальнейшему получению прибыли), для операционного отдела преимуществом является удобность и лаконичность в пользовании программой, риски же стремятся минимизировать вероятность невыплат по кредитам, отбирая, тем самым, только «нерискованных» клиентов.
1.4.2 Анализ применимости моделей жизненного цикла в банковской сфере
Суммируя информацию, характеризующую банковскую сферу, можно отметить, что внедрение IT-проекта в банк с большей долей вероятности будет претерпевать постоянные изменения в требованиях к функционалу программного обеспечения. Стоит также добавить, что для заказчика (в данном случае, для Банка) внедряемое ПО является инструментом для исполнения функций, соответствующих характеру его бизнеса, а так как конфликты между отделами банка встречаются довольно часто, то и к общему соглашению отделы будут приходить постепенно, постоянно меняя решения.
Проанализировав специфику банковской сферы, а также особенности IT-проектов, можно предположить, что применение водопадной модели в данном контексте не является целесообразным решением.
При водопадной модели каждое изменение или неточность какого-либо требования принуждают команду проекта возвращаться на более раннюю фазу и повторять проделанную работу заново. Эта переработка выбивает проектную команду из графика и нередко приводит к росту затрат. Несмотря на то, что команда проекта может постараться подготовить грамотное техническое задание, демонстрирующее, на их взгляд, каждый аспект разрабатываемого программного продукта, вероятность обнаружения расхождений в дальнейшем все же велика, причем эти расхождения могут быть заметны только на этапе тестирования.
Как известно, стоимость исправления ошибок в проекте прямо пропорциональна его длительности. Таким образом, ошибки в требованиях, обнаруженные на этапе тестирования, могут быть катастрофическими как для финансовой стороны компании, так и для всего проекта в целом. Таким образом, применение водопадной модели жизненного цикла может спровоцировать появление проблем, характерных IT-проектам в быстро меняющихся средах.
Стоит обратить внимание на применение «гибкой» методологии управления этим IT-проектом, объединяющей в себе преимущества итеративной и спиральной моделей жизненного цикла. В условиях быстро меняющихся требований и нестабильной окружающей среды подход, который предлагает внедрять или разрабатывать программное обеспечение по частям с постоянным отслеживанием готового продукта и с постоянной коммуникацией между заказчиком и разработчиками, может быть намного результативнее, чем последовательное внедрение программы с большими объемами документации, что предлагает традиционный водопадный подход.
Глава II. «Гибкие» методологии управления IT-проектами
2.1 Описание и принципы «гибких» методологий управления IT-проектами
Как было упомянуто ранее, теория «гибких» методологий появилась после осознания преимуществ итеративной и спиральной моделей жизненного цикла по сравнению с традиционной водопадной моделью. В феврале 2001 года состоялась встреча создателей методологии сочетающих в себе основные принципы итеративной и спиральной модели.
На этой встрече было решено назвать такие методологии общим словом «гибкие» (agile). «Гибкая» методология - это итеративный процесс, использующий уникальные практики для получения нового функционала программного обеспечения каждые 1-4 недели (Rubio, 2008).
Тогда же в 2001 году были созданы два основополагающих документа: «Манифест гибких методологий разработки» и «Принципы гибкой разработки». В первом из них четко прописаны высокоуровневые ценности, которым уделяется внимание в процессе управления IT-проектом:
«Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану» [39].
Первая ценность говорит о том, что вне зависимости от того, какими бы важными процессы и инструменты ни были, успех проекта зависит, в первую очередь, от вовлеченных в этот проект людей, т.е. в «гибких» методологиях очень важным является человеческий фактор, а именно возможность организации эффективной коммуникации, легкость преодоления конфликтов и так далее. Вторая ценность вовсе не исключает документацию, наоборот, она упрощает возможность взаимодействия и сотрудничества, а также налаживает процесс передачи знаний, однако эффективное взаимодействие между людьми намного лучше сказывается на проекте, нежели хорошо описанная документация без взаимодействий внутри команды.
Третья ценность подразумевает, что непрерывное общение между заказчиком и командой разработчиков является более целесообразной стратегией, нежели «война» сторон за правильную трактовку ранее подписанного контракта. «Современная практика реализации проектов, как правило, сопровождается затяжными переговорами между участниками. Разумеется, переговоры - один из важнейших элементов деловой практики. Но зачастую они превращаются в игру с нулевой суммой: одна из сторон пытается обеспечить собственные интересы за счет другой стороны» [14, с. 88]. «Гибкие» методологии противопоставляют такой «борьбе» диалог между разработчиками и заказчиками. Такой подход позволяет выигрывать двум сторонам общими усилиями. Последняя четвертая ценность призывает команду проекта быть постоянно готовыми к изменениям. Ни один IT-проект не может заранее быть спроектирован целиком и полностью, со всеми учтенными нюансами. «Гибкие» методологии не отрицают необходимость досрочного планирования, они лишь допускают внесение корректировок в течение времени, отведенного для реализации IT-проекта.
В «Принципах гибкой разработки» детализируются основные ценности из «Манифеста». Эти двенадцать конкретизированных ценностей являются синтезом основополагающих принципов итеративной и спиральной моделей. Они позволяют организовать дисциплинированный гибкий процесс управления IT-проектом, проводя всю работу итерациями с промежуточными проверками, создавая слаженную самоорганизующуюся команду разработчиков и осуществляя постоянную коммуникацию с заказчиком. («частые поставки продукта», «частая поставка новых версий программного обеспечения», «методы взаимодействия и обмена информацией», «техническое совершенство и качественная архитектура»). Важно отметить, что именно налаженное взаимодействие между участниками проекта способно гарантировать быстроту исполнения.
Гэри Чин в своей книге «Agile Project Management: How to Succeed in the Face of Changing Project Requirements» (Chin, 2004) более детально перечисляет факторы проекта, наличие которых должно служить сигналом для использования именно «гибкой» методологии управления IT-проектом. Данные факторы автором разделяются на две группы: «внутренние неопределенности» и «внешние неопределенности» (рисунок 6):
Рис. 6 Внутренние и внешние неопределенности проекта
Если проект подвержен каким-то внутренним или внешним неопределенностям, то вполне благоразумно будет планировать его жизненный цикл, используя «гибкие» методологии.
При использовании «гибких» методологий задачи проекта разбиваются на малые части (итерации) с тщательным краткосрочным планированием и почти незначительным долгосрочным планированием. Если в классической итеративной модели длина итерации может быть сколь угодно большой (но в разумных пределах), то «гибкие» методологии ограничивают время, отведенное на выполнение конкретной итерации, до пяти недель.
«Гибкие» методологии базируются на эмпирическом управлении, то есть на таком управлении, где решения принимаются, исходя из промежуточных результатов проекта. Кроме того, данные результаты являются прозрачными, что означает, что все вовлеченные в проект люди осведомлены статусом работ по проекту, количеством изменений и возможными проблемами. (Layton, 2012). Нельзя не отметить, что в случае IT-проектов эмпирическое управление позволяет быстро вносить корректировки в программный продукт, и это является большим преимуществом по сравнению с водопадной моделью жизненного цикла.
Последние несколько лет в США проводилось много исследований, направленных на изучение преимуществ «гибких» методологий по сравнению с традиционной водопадной моделью. Например, согласно седьмому ежегодному государственному исследованию «гибкой» разработки Интернет-ресурса Version One, 84% респондентов (разработчиков) признали, что «гибкие» подходы кажутся им более эффективными, чем традиционные подходы.
Кроме того, 70% респондентов этого же исследования признали, что IT-проекты, внедряемые с помощью «гибких» методологий, реализовываются намного быстрее IT-проектов, внедряемых с помощью водопадной модели жизненного цикла (рисунок 7):
Рис. 7 Проекты внедряются быстрее, если используется "гибкая" методология
В качестве завершающего этапа анализа природы «гибких» методологий и их преимуществ ниже приведена таблица, в которой еще раз указаны основные различия «гибких» методологий и водопадной модели, которые не были отражены явным образом в «Манифесте»:
Таблица 1 Ключевые различия «гибких» методологий и водопадной модели
|
«Гибкие» методологии |
Водопадная модель |
||
|
Требования заказчика |
Итеративный сбор |
Детализированные требования четко определяются до начала фазы непосредственного внедрения |
|
|
Стоимость доработок |
Низкая |
Высокая |
|
|
Направление разработки |
Может быть изменено в любой момент |
Фиксированное |
|
|
Тестирование |
После каждой итерации |
Во время соответствующей фазы, следующей за внедрением/разработкой |
|
|
Вовлеченность заказчика |
Высокая |
Низкая |
2.2 Обоснование выбора методологии «скрам» для моделирования процесса управления IT-проектом
В настоящее время существует множество гибких методологий, но наиболее популярными являются «экстремальное программирование» (XP), «скрам», «бережливая разработка» (lean), «разработка, управляемая функциональностью» (fdd) и «канбан».
В таблице 2 приведен сравнительный анализ данных методологий (Abrahamsson, 2002):
Таблица 2 Сравнительный анализ "гибких" методологий
|
Название |
Ключевые моменты |
Уникальные особенности |
Недостатки |
|
|
«экстремальное программирование» (XP) |
Маленькие команды, ежедневные совещания, неформальный тип коммуникации внутри команды, минимум документации |
Постоянное корректирование проекта для повышения его эффективности и для адаптации к изменениям |
Больше подходит для индивидуальных практик, чем для глобального управления, так как в последнем случае есть риск формирования недисциплинированных команд |
|
|
«скрам» |
Независимая, небольшая, самоорганизующаяся команда разработчиков, длина итерации - 2-4 недели, команда сама решает сколько времени ей нужно для выполнения задачи, неформальный тип коммуникации внутри команды, ежедневные совещания, присутствует только базовая документация |
Высокий уровень коммуникации и взаимодействия внутри команды, четко прописанная формальная организация этой методологии, наличие «надсмоторщика» за командой, полная ориентация на требования заказчика |
Есть риск увеличения времени проекта за счет издержек «скрам»-мероприятий |
|
|
«бережливая разработка» (lean) |
Использование визуализирующих инструментов, разработка через тестирование, короткие итерации |
Главными являются те функции ПО, которые ценны для заказчика, присутствует постоянное мотивирование команды |
Решения принимаются долго, недостаток дисциплины, походит только для маленьких проектов |
|
|
«разработка, управляемая функциональностью» (fdd) |
Пяти шаговый процесс, объектно-ориентированная разработка, очень короткие итерации (могут достигать по длительности несколько часов) |
Простота метода, объектное моделирование |
Данная методология фокусируется только на проектировании и внедрении, очень мало внимания уделено именно разработке |
|
|
«канбан» |
Самоорганизующаяся команда, утерянный смысл понятия «итерация» - весь упор на задачи |
Нет ограничений по времени выполнения, зато есть ограничение на число «работы в данный момент |
Недостаток дисциплины, затяжной характер |
FDD фокусируется на пяти шаговом подходе, который базируется на идентификации, разработке и внедрении характеристик. В FDD также полагается, что часть работы по проекту уже сделана. В результате, многие фазы проекта остаются не до конца реализованными. «Канбан» может быть эффективен внутри конкретной организации, даже внутри какого-то отдела, в случае сложных контрактных отношений «заказчик-исполнитель» он очень трудно реализуем.
«Бережливая разработка» и «экстремальное программирование» тоже теряют свою эффективность, когда в проект вовлечено более чем одна организация: отсутствие явного наблюдателя за процессом может создать путаницу в обязанностях.
Методология «скрам» нацелена на взаимодействие с заказчиком, и, несмотря на то, что команда разработчиков сама решает, какие задачи она будет выполнять в течение одной итерации, в данной методологии присутствует наблюдатель (Скрам-мастер), который контролирует соблюдение «скрам»-процесса. Помимо всего прочего, «скрам» хорошо документирован: существует специальное «руководство по скраму», переведенное на многие языки мира. Определенная степень формализованности в терминах «гибкой» методологии разработки является наилучшей стратегией управления IT-проектом, когда в проекте участвуют люди из разных организаций.
«Скрам» - наиболее популярная «гибкая» методология, широко используемая зарубежными компаниями, такими как Yahoo!, PayPal, Nike, Google, SAP, GE для управления проектами (Deemer, 2007). Согласно шестому и седьмому ежегодным государственным исследованиям «гибкой» разработки Интернет-ресурса Version One, методология «скрам» используется как метод «гибкого» управления IT-проектом в несколько раз чаще, чем остальные методологии (рисунок 8 и рисунок 9):
Рис. 8 Популярность методологии "скрам" в 2011 году
Рис. 9 Популярность методологии "скрам" в 2012 году
2.3 Описание методологии «скрам»
Методология «скрам» была впервые представлена в 1990-х годах Кеном Швабером и Джефом Сазерлендом в виде четко задокументированного и формализованного «руководства по «скраму».
«Скрам» - это гибкий и легкий процесс управления и контроля программным обеспечением и процесса разработки продукта в быстро меняющихся условиях» [28, с. 19]. Данная методология устанавливает определенные правила управления IT-проектом (разработкой или внедрением информационной технологии), которые основываются на возможности постоянной корректировки требований и на внесении тактических изменений.
Перед началом проекта участники обсуждают глобальные цели и базовую стратегию, направленную на достижение этих целей. Лицо со стороны Заказчика проекта представляет интересы своей компании путем описания бизнес-функций внедряемого или настраиваемого программного обеспечения.
Со стороны исполнителя определяется состав команды разработчиков и другие ресурсы, после чего сторонами обсуждаются примерные рамки проекта, а так же дата начала первой итерации. Итерация в «скраме» получила название спринт, и она длится две-четыре недели. Все спринты имеют относительно фиксированную длительность: это означает, что если запланирована дата окончания спринта, то при наступлении этой даты (с минимальной погрешностью) все работы данного спринта должны закончиться, вне зависимости от того, успела ли команда проекта выполнить задание или нет. Минимальная погрешность означает, что на практике какие-то задержки все же возможны, но, тем не менее, они не должны превышать двух-трех дней для спринта, длительность которого равняется двум неделям.
Модель методологии «скрам» состоит из трех главных компонентов: ролей, артефактов и мероприятий. В данной методологии присутствуют три роли: Владелец продукта, Скрам-мастер и Скрам-команда.
· Владелец продукта чаще всего является заказчиком, который поддерживает в актуальном состоянии список требований к проекту. Чем лучше и четче владелец продукта опишет требования, тем меньше будет вопросов у разработчиков, тем реже будет изменяться функционал программного обеспечения с течением времени.
Именно Владелец продукта определяет приоритет требований, то есть сам заказчик решает, какие функции программного обеспечения являются наиболее срочными и важными для компании на какой-то конкретный момент;
· Скрам-мастер ответственен за понимание сущности всего «скрам»-процесса другими участниками. Скрам-мастер чем-то похож на традиционного менеджера проекта, но у него есть одно отличие: он не отдает явных приказов и не устанавливает сроки разработчикам, он, напротив, помогает им при возникновении каких-либо трудностей и следит, чтобы их работа была слаженной. Именно от Скрам-мастера зависит атмосфера в команде разработчиков, а, как следствие, и их инициативность, удовлетворенность и общий результат. Скрам-мастер решает любые проблемы, которые могут как-то помешать команде, будь то сломанное оборудование или внешнее давление со стороны заказчика. Скрам-мастер также следит, чтобы все события «скрама» (о которых будет написано ниже) происходили регулярно и с максимальной эффективностью;
· Скрам-команда «…состоит из профессионалов, выполняющих работу по разработке потенциально «готового» к выпуску новой версии продукта в конце каждого «спринта» [36, с. 5]. Обычно количество разработчиков и программистов не превышает восьми, и все они являются заинтересованными в успешной реализации IT-проекта. Перед началом каждой итерации Скрам-команда ставит достижимую и значимую для заказчика цель, а во время итерации направляет все свои усилия на достижение этой цели в срок с заявленным качеством. Достижение цели характеризуется наличием запланированного кода, который впоследствии был отлажен, а возможные дефекты итерации устранены. Скрам-команда сама устанавливает себе сроки (обсудив их со Скрам-мастером и Владельцем продукта), сама оценивает свои возможности и распределяет время.
Среди артефактов методологии «скрам» выделяют журнал продукта, журнал спринта и диаграммы сгорания (рисунок 10):
Рис. 10 Артефакты методологии "скрам"
Журнал продукта создается Владельцем продукта (заказчиком) после анализа потребностей бизнеса в виде списка требований к программному обеспечению. Иными словами, заказчиком описываются главные желаемые функционалы разрабатываемой или внедряемой программы. После этого каждому требованию приписывается степень важности для заказчика, то есть приоритет, причем наиболее приоритетные задачи должны находиться выше по списку в журнале продукта, чем наименее приоритетные. В течение всего проекта Владелец продукта имеет право добавлять в журнал продукта новые требования или модифицировать старые. Именно такая возможность позволяет данному подходу быть «гибким к изменениям». В реальной жизни у заказчика может постоянно меняться список требований к программному обеспечению, соответственно, Владелец продукта может вести их непосредственный учет и служить «соединяющим» звеном между компанией-заказчиком, интересы которой Владелец продукта представляет, и Скрам-командой (разработчиками). Выбранные на определенный спринт требования из журнала продукта заносятся в журнал спринта.
Схематически это можно представить следующим образом (рисунок 11):
Рис. 11 Формирование журнала спринта
В отличие от журнала продукта, который может быть изменен или пополнен Владельцем продукта в любой момент времени проекта, журнал спринта на время конкретной итерации является фиксированным и утвержденным командой. Задачи из журнала спринта могут быть исключены только в форс-мажорных ситуациях, когда их выполнение больше не будет нацелено на успех всего IT-проекта. Как было сказано ранее, методология «скрам» вовсе не исключает документацию полностью, ее просто намного меньше, чем в традиционном подходе водопадной разработки. На практике все решается Владельцем продукта и Скрам-командой: если обе стороны приходят к соглашению оформить процесс реализации какой-то задачи из журнала продукта, то разработчиками создается соответствующий небольшой документ. Данный документ не будет являться подобием технического задания, на него не будут ссылаться при обсуждении контрактных условий, он необходим для более конкретного понимания функционирования каких-либо частей программы.
Для того чтобы вести учет объема выполненной работы, а также объема предстоящей работы, используются диаграммы сгорания. Перед каждой итерацией команда планирует количество усилий, которое необходимо для выполнения задач из журнала спринта. После завершения каждой задачи Скрам-мастер пересчитывает количество оставшейся работы на этот спринт. Эти значения отмечаются на графике, где по оси абсцисс находится длительность спринта, а по оси ординат количество оставшейся работы. Диаграмма сгорания полезна в качестве вспомогательного инструмента, позволяющая оценить, в правильном ли направлении идет работа команды в рамках конкретного спринта.
Помимо спринта в методологии «скрам» существуют еще четыре мероприятия: планирование спринта, ежедневное совещание, обзор итогов спринта и ретроспективное совещание. Перед началом спринта происходит его планирование. Сначала Владелец продукта демонстрирует журнал продукта, в котором находятся требования к программному обеспечению, отсортированные по приоритету на конкретный момент. При этом Владелец продукта обсуждает со Скрам-командой возможные нюансы задач, тем самым, минимизируя возможность появления субъективизма в разработке. После этого команда выбирает наиболее важные задачи из журнала продуктов, которые помещаются в журнал спринта. Ключевым момент здесь является определение необходимого времени для выполнения этих задач самими разработчиками. Так как в данном случае они все решают сами, без внешнего принуждения от менеджера проекта, то вероятность к неоправданному завышению времени минимальна. После того, как задачи на следующий спринт назначены, Скрам-команда начинает между собой обсуждать каждую из них более подробно. Для успешного выполнения задачи, она может детализироваться понятным разработчикам образом на мини-задачи. Кроме этого, Скрам-команда обсуждает сам процесс разработки кода, взаимозависимость между различными компонентами и так далее. Иными словами, разработчики решают, как они будут реализовывать требование заказчика. Методология «скрам» нацелена на организацию слаженной работы внутри команды. Планирование спринта длится около четырех часов и главным результатом этого мероприятия является договоренность между Владельцем продукта и Скрам-командой по поводу количества задач, над которыми будут вестись работы в течение планируемого спринта, а так же уверенность в том, что понимание пришло ко всем участникам встречи. Несмотря на «гибкость» методологии «скрам», команда должна быть уверена в неизменности и стабильности задач в рамках конкретного спринта. Если Владелец продукта хочет поменять требования, то для этого ему стоит дождаться планирования следующего спринта. Такой подход одновременно «гибок» и одновременно защищает проект от возможного беспорядка и разногласий. После окончания планирования начинается спринт. Каждый рабочий день Скрам-мастер организует короткое совещание, не превышающее по длительности пятнадцати минут. Целью ежедневного совещания является предоставление возможности участникам команды поделиться собственным прогрессом и возникшими трудностями. Каждый участник команды отвечает на три вопроса:
...Подобные документы
Теоретические основы, сущность и методы, специфика и особенности оценки стратегического управления в банковской сфере. Особенности стратегического управления в Банке "Союз": выявленные проблем, предложения по совершенствованию и зарубежный опыт.
дипломная работа [98,5 K], добавлен 06.06.2012Проблемы управления рисками: повышения уровня профессиональных знаний, мониторинг использования банковских средств и внедрение системы менеджмента качества банковской сферы. Состояние потребительского кредитования и вкладов в инновационную деятельность.
реферат [59,0 K], добавлен 20.03.2011Понятие системных рисков в банковской сфере, критерии их идентификации и оценка. Основные классификационные признаки группирования банковских рисков. Влияние системных рисков на стабильность, устойчивость, надежность и равновесие банковской сферы.
реферат [727,1 K], добавлен 22.02.2017Сущность, виды, факторы и методы оценки процентного риска. Анализ уровня процентных рисков в банковской деятельности Республики Беларусь. Связь между доходностью операций банка и его риском. Совершенствование управления рисками в банковской сфере.
курсовая работа [91,8 K], добавлен 07.11.2015Цель создания системы управления рисками в банковской сфере. Систематизация работы подразделений, взаимодействующих с клиентами. Применение хранилищ данных для оперативного принятия управленческих решений. Технологии удаленного банковского обслуживания.
курсовая работа [1,3 M], добавлен 12.05.2011Понятие кризиса и причины его возникновения. Основные этапы развития кризисной ситуации. Коммуникационные стратегии в разрешении кризисной ситуацией. Влияние негативных технологий в банковской сфере. Механизмы защиты банков от негативных технологий.
курсовая работа [82,1 K], добавлен 06.10.2015Описание бизнес-процессов кредитования, протекающих в банке. Построение модели предприятия "как есть". Формирование требований к автоматизированной банковской системе. Экономическое обоснование ее разработки, состав и содержание работ по созданию.
отчет по практике [1,4 M], добавлен 12.06.2013Предмет, метод и задачи банковской статистики, ее информационное обеспечение и система показателей. Значение группировки, вариация и ее показатели. Статистическое исследование банковской деятельности в Российской Федерации. Взаимосвязи в банковской сфере.
реферат [78,8 K], добавлен 09.09.2014Эволюция взглядов на сущность экономической категории "конкуренция", ее особенности в банковской сфере; виды, классификация. Тенденции и закономерности конкуренции, ее влияние на содержание, формы и методы конкурентной борьбы на рынке банковских услуг.
контрольная работа [1,2 M], добавлен 25.09.2011Изучение особенностей организации маркетинга в банковской сфере. Развитие информационной системы учета в коммерческом банке. Использование специальных методик бухгалтерского учета. Организационная структура и управление фирмой. Теория менеджмента.
отчет по практике [307,8 K], добавлен 29.06.2015Теоретико-методологические основы банковской деятельности. Центральный банк - главное звено банковской системы. Основные черты и особенности функционирования банковской системы России на современном этапе, ее главные проблемы и модели их решения.
курсовая работа [84,8 K], добавлен 11.10.2013Сущность банковского менеджмента. Контроль банковской деятельности. Анализ управления персоналом. Эффективность менеджмента в банке. Направления совершенствования менеджмента в Набережночелнинском отделении Сбербанка РФ. Оценка положения банка на рынке.
курсовая работа [50,6 K], добавлен 14.12.2013Изучение теоретических основ и определение банковской деятельности. Рассмотрение основных принципов деятельности коммерческого банка; анализ ее правового регулирования. Государственное косвенное управление экономическими методами в данной сфере.
курсовая работа [43,4 K], добавлен 23.07.2015Развитие и внедрение новых технологий и новых способов взаимодействия с клиентами в банковской сфере. Использование бесконтактных смарт-карт. Сравнение мобильного банкинга "Ощадбанка" и "Юникредит банка". Перевод денежных средств и пополнение карты.
эссе [16,7 K], добавлен 10.10.2015Изучение вопросов становления правовой базы валютного регулирования в Российской Федерации. Раскрытие роль Центрального Банка в регулировании валютных операций. Выводы и предложения по совершенствования валютного контроля в сфере банковской деятельности.
курсовая работа [40,0 K], добавлен 12.06.2015Исследование особенностей управления кредитными рисками на основе методологии, предложенной Базельским комитетом. Анализ системы управления кредитными рисками в РБ. Проблемы управления кредитными рисками, их воздействие на стабильность банковской системы.
курсовая работа [1,3 M], добавлен 03.10.2014Развитие кредитной кооперации в России, связь данного процесса с явлением кулачества. Формирование банковской системы в результате национализации после 1917 года. Оценка роли Сбербанка банковской сфере России в советские времена и на современном этапе.
контрольная работа [37,9 K], добавлен 03.12.2013Организация и сущность банковской системы Российской Федерации. Понятие кредита; его функции и виды. Ознакомление с принципами кредитования физических лиц на примере Сберегательного Банка России. Совершенствования управления кредитных портфелем.
курсовая работа [181,7 K], добавлен 16.06.2014Понятие банковской системы, ее типы и структура. Эволюция и современное состояние банковской системы. Перспективы реформирования банковской системы Российской Федерации. Структурный анализ пассивов и активов ОАО Банка "ВТБ24", ликвидности баланса.
курсовая работа [116,2 K], добавлен 21.04.2011Экономическая сущность и классификация рисков банковской деятельности. Построение системы риск-менеджмента в организации. Оценка кредитного риска, потери ликвидности и доходности. Показатели измерения VаR, методика расчета величины в Республике Беларусь.
курсовая работа [166,4 K], добавлен 14.11.2013
