Создание модели оценки системных решений в банковском секторе на примере ведущего российского банка
Системная архитектура и автоматизированные процессы как неотъемлемая часть деятельности любой компании в современных реалиях. Анализ особенностей создания модели оценки системных решений в банковском секторе на примере ведущего российского банка.
| Рубрика | Банковское, биржевое дело и страхование |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 04.12.2019 |
| Размер файла | 1,5 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Создание модели оценки системных решений в банковском секторе на примере ведущего российского банка
Введение
В современных реалиях системная архитектура и автоматизированные процессы - неотъемлемая часть деятельности любой компании. Масштаб и сложность автоматизации определяются многими факторами: от организационной структуры компании до специфики индустрии, в которой организация занимает нишу. Стремление компаний перенести процессы в бизнес-приложения объясняется измеримым экономическим эффектом. Например, сокращается скорость выполнения шагов процесса, снижаются операционные затраты или риски потери данных. Автоматизация также позволяет фиксировать состояние процессов по заданным метрикам в определенный момент времени и накапливать статистическую информацию для их анализа в различных срезах. В свою очередь, это дает возможность задать контрольные значения для управления процессом. Управляемый процесс - это предсказуемый процесс, в котором при изменении некоторых параметров можно спрогнозировать изменение его поведения. Также, на основании статистических данных о состоянии процесса можно с принимать бизнес-критичные решения, которые могут дорого стоить бизнесу в случае ошибки.
Однако, перенос бизнес-процессов в системный функционал всегда имеет ряд рисков, а оценка и минимизация таких рисков являются главной задачей представителей ИТ-слоя компании. Один из таких рисков - реализовать необходимый бизнесу функционал не самым оптимальным способом. Зачастую «не оптимальность» системного функционала связана не с ошибками проектирования или отсутствием экспертизы у системных аналитиков и архитекторов, а намеренным решением внедрить временную доработку, потому что бизнесу она срочно нужна. «Не оптимальность» таких доработок с точки зрения системных приложений может заключаться в дублировании кода и отсутствии его переиспользования, в нелогичной декомпозиции системы на компоненты, в реализации прямой интеграции между системами вместо использования промежуточного ПО, приводящей к высокой зависимости систем, и т.д. Как правило, такие временные решения предполагается заменять целевым вариантом, когда на это будут время и ресурсы, но в реальности до рефакторинга такого функционала часто не доходят руки, и у команд разработки копится технической долг. Временные доработки приживаются в системах и становятся причиной новых временных и неэффективных доработок. Через некоторое время система становится плохо управляемой, медленной в работе и сложной к пониманию.
Таким образом, проблема системного проектирования заключается в сложности оценки соотношения выгоды, полученной благодаря быстрому внедрению временного функционала, к затратам, которые придется понести при последующем рефакторинге или выводе из эксплуатации неуправляемой системы. В отраслях, где быстрая реакция на изменения рынка и спроса дает конкурентное преимущество и приносит большую прибыль, особенно важно взвешивать выгоду от поспешных доработок и затраты на последующее изменение функционала. Одной из таких отраслей является банковская, поэтому тема данной магистерской диссертации - «Создание модели оценки системных решений в банковском секторе на примере ведущего российского банка».
Актуальность выбранной для исследования тематики объясняется критичностью системных решений для бизнеса: быстрое внедрение нового функционала может помочь банку вывести на рынок новый продукт или запустить новый автоматизированный процесс раньше конкурентов. Это позволяет банку занять большую часть ниши и привлечь множество клиентов, а конкурентам, вышедшим на рынок с аналогичным продуктом позже, придется соперничать за оставшихся потенциальных клиентов и вкладываться в стратегии переманивания. Несмотря на очевидную выгоду стремительного внедрения, риски рефакторинга функционала высоки и могут серьезно замедлить бизнес-процессы в будущем, вплоть до необходимости вывода системы из эксплуатации и замены ее на новое программное обеспечение. В связи с этим, наличие модели, позволяющей заранее оценить и взвесить риски и выгоды внедрения системного обновления, очень актуально для продакт-менджеров банковских направлений.
Для данной магистерской диссертации объектами исследования являются функционал банковского приложения и модель принятия решений о целесообразности внедрения системной доработки. Предметом исследования выступает платформа Pega и разработанная на ней банковская CRM система Sales Force Automation (SFA) «АО Альфа-банка». Гипотеза на момент начала исследования: наличие модели для принятия решений о целесообразности внедрения функционала поможет банку избежать неэффективных доработок, повысить качество системы и минимизировать необходимость рефакторинга.
Главной целью данной магистерской диссертации является разработка модели оценки целесообразности внедрения функционала, состоящей из качественного и статистического инструментов оценки. Предложенная модель будет учитывать, как экспертные оценки, так и количественные метрики функционала. Также целью является формирование набора рекомендаций по использованию этой модели. Для достижения поставленных целей будут выполнены следующие задачи:
- рассмотреть публикации на тему роли CRM в деятельности банка и необходимости системного рефакторинга;
- определить степень проработанности проблемы и новизны предлагаемой модели;
- изучить основные направления предназначения платформы Pega;
- предоставить описательную характеристику SFA - CRM-системы Альфа-Банка;
- описать 2 кейса рефакторинга системы SFA;
- предложить модель оценки системного решения, состоящую из качественного и статистического методов;
- сравнить результаты применения предложенной модели к реальным кейсам рефакторинга.
Для достижения поставленных целей и задач будут использованы следующие методы: для подтверждения актуальности и определения степени проработанности проблемы использованы теоретические методы анализа и обобщения; для изучения предмета исследования применены методы описательной характеристики и сравнения; для построения модели оценки использованы качественный метод решения неструктурированных проблем и статистический метод, описывающий зависимость переменных модели.
Данная магистерская диссертация представлена в 4 главах. В первой главе представлен обзор публикаций по исследуемой тематике. В обзоре рассмотрены статьи, описывающие основные особенности и значимость банковской CRM, изучено явление рефакторинга, и обозначено экспертное мнение об этом явлении. Также, в главе приведены основные причины перепроектирования внутреннего системного функционала. Основными источниками в этой главе являются статьи и публикации преимущественно зарубежных специалистов. Обзор статей направлен на поиск подтверждения актуальности исследуемой тематики.
Во второй главе описаны основные особенности платформы Pega, на которой разработана исследуемая банковская CRM, описаны основные сферы её применения, и приведен сравнительный анализ этой платформы с некоторыми другими решениями. Кроме того, в главе дана характеристика самой исследуемой системы SFA «АО Альфа-банка». Характеристики составлены на основе данных вендора Pegasystems и консалтинговой компании Gartner.
В третьей главе приведены 2 примера временных решений в рассматриваемой системе Pega SFA, и дана экспертная оценка эффекта доработки на проект или бизнес. Данные для исследования предоставлены продакт-менеджером системы.
В четвертой главе составлена модель оценки целесообразности внедрения определенного функционала, описаны принципы работы модели и интерпретация результатов, а также рассмотрены результаты применения этой модели к двум кейсам рефакторинга в SFA.
В заключительной части подведены итоги исследования и приведен список рекомендаций по применению модели на практике.
1. Обзор публикаций
банковский системный автоматизированный
Оценить, насколько программное обеспечение улучшает процессы компании или повышает её прибыль, с точностью до рубля зачастую нельзя, поскольку многие приобретенные экономические эффекты (как положительные, так и отрицательные) довольно сложно точно спрогнозировать. Однако, всегда можно предположить, каких системных и бизнес изменений можно достичь, внедряя тот или иной функционал. В банковском секторе ошибки в системном приложении могут стоить особенно дорого, потому что сама по себе отрасль является динамичной и высоко прибыльной, где даже кратковременный отказ приложений может послужить причиной оттока большого числа клиентов и потери их лояльности. Кроме того, упустив момент привлечения клиентов на новый продукт, банк рискует никогда этих клиентов не заполучить, потому что клиент, однажды подписав договор на обслуживание с другим банком, часто не готов менять поставщика услуг. Конечно, есть продукты, по которым переманить клиента из другого банка просто, например, моментальные дебетовые или кредитные карты. Но есть и другая группа продуктов: крупные кредиты и ипотеки, зарплатные проекты, торговые и интернет эквайринги, по которым менять обслуживание клиент готов гораздо реже, поэтому потеря этих сегментов для банка не допустима. В связи с этим, оценка целесообразности внедрения определенного функционала в банковском секторе особенно уместна.
Поскольку в практической части данной магистерской диссертации подробно описана банковская СRM система SFA на платформе Pega, и модель оценки применена именно к этому функционалу, в данной главе проводится анализ публикаций касательно CRM систем в банковском секторе. Также, в главе показано то, как проблема неэффективного рефакторинга отражается в современных статьях зарубежных и российских авторов.
Понимание потребностей клиента для банка - одна из наивысших ценностей и способ выжить в своем секторе, поэтому банки инвестируют большие средства в проекты внедрения CRM систем и развитие проектов KYC (Know Your Customer). KYC - определенная экспертиза и набор правил и техник, которых банки (или другие финансовые и юридические организации) придерживаются для максимальной идентификации своего клиента. Это позволяет им строить стратегии взаимодействия наиболее эффективно [1]. Направление KYC развивается не только для того, чтобы пресечь незаконную активность клиента (кражу и мошенничество, отмывание денег, финансирование терроризма и т.д.), но и для управления рисками, связанными с займом денег и перекредитованием долгов.
Кроме проверки клиентов на благонадежность, KYC-система направлена на поддержку бизнес-стратегии построения долгосрочных и прибыльных отношений с ценными клиентами. Большинство финансовых организаций создают ценность для своих потребителей за счет предложения им постоянно растущего числа финансовых продуктов, отвечающих их потребностям. Подход массового маркетинга вытесняется управлением взаимоотношениями с клиентами (CRM) - принципиально другим подходом, при котором привлечение клиентов является лишь одним из этапов прогнозируемых долгосрочных отношений между бизнесом и их клиентами [2].
Нигде преимущества CRM не ощущаются больше, чем в финансовых организациях. Раньше обеспечить клиенту положительный потребительский опыт в работе с банком было относительно не сложно для опытного банкира. Однако, сейчас диверсификация продуктов и их география слишком обширны, а каналы привлечения и продаж многочисленны, поэтому бизнесу приходится персонализировать взаимоотношения с клиентами.
Банковские CRM системы поддерживают все виды коммуникации с клиентом, а также продажи и последующее обслуживание. С помощью этих систем банки могут предсказывать поведение клиентов, например, предсказать отток или определить, в каких еще продуктах клиент может быть заинтересован.
Основные цели внедрения CRM системы в банке следующие:
· Предоставление более качественного сервиса за счет сбора обратной связи от клиента;
· Идентификация отличительных ценностей каждого сектора рынка и потребителей;
· Улучшение взаимоотношений с ключевыми клиентами;
· Увеличение выручки от предоставляемых сервисов;
· Формирование клиентской лояльности;
· Повышение точности сегментации клиентов;
· Установление афеллированности лиц/компаний;
· Построение клиентоориентированной культуры;
· Автоматизация распределения ресурсов на группы потребителей [3].
Внедряя CRM систему, бизнес стремиться достичь всех или части из вышеперечисленных целей. Управление взаимоотношениями с клиентами влияет на качество предоставляемого продукта и, как следствие, росту доли на рынке и прибыли. В статье, опубликованной в «Pakistan Administrative Review», авторами приводится исследование, хорошо иллюстрирующее это утверждение. В своем исследовании авторы изучают влияние CRM-практик на качество услуг, предоставляемых в банковском секторе. Исследование подробно рассматривает 3 CRM-аспекта: отношение к клиентам, эффективность предоставляемой банковской услуги и информированность сотрудников банка и их влияние на качество продукта. Когда пользователи осведомлены о предоставляемых услугах, они имеют возможность влиять на их качество. Исследование включает в себя опрос, предложенный 230 респондентам, которые были клиентами разных банков. Результаты исследования показывают, что информированность и отношение к клиентам со стороны банковских работников - главные факторы, которые укрепляют лояльность клиента по отношению к продукту или услуге и банку в целом. Более всего с удовлетворением клиента связано отношение сотрудников банка к потребителям [4]. Таким образом, все три аспекта, рассмотренные в этом исследовании полностью покрываются CRM-практиками, и в каждое вендорское решение CRM-системы, как правило, встроены референтные модели, направленные на развитие каждого из этих трех аспектов.
Однако, эмпирических исследований на тему влияния информационных систем на деятельность компаний, в частности банков, довольно много, а исследований с реальными математическими моделями, применимыми для оценки влияния ИТ на банковский сектор, значительно меньше. Это связано с тем, что сбор статистики и наблюдений для оценки влияния системы на поведение клиента - процесс длительный, и не всегда очевидно, какие изменения действительно значимы. Поэтому проблема значимости систем в банковской деятельности раскрыта не полностью и статистическими данными подкреплена редко. Одна из публикаций, в которой эффект от CRM-системы в банковской индустрии был подтвержден математически, - статья «The Impact of Information Technology on the Banking Industry: Theory and Empirics» [5]. В этой статье рассмотрено влияние ИТ на банковский сектор США. Авторы подтверждают заявленную гипотезу о том, что использование систем приводит к снижению затрат, но их эффект на доходность банка остается неявным, т.к. имеют влияние так называемые сетевые эффекты, которые возникают при конкуренции банков за предоставление финансовых услуг. В исследовании рассмотрено теоретически и эмпирически, как инвестиции в информационные технологии влияют на прибыль банков. За основу взята модель Хотеллинга (модель пространственной дифференциации рынка с монополистической конкуренцией, которая демонстрирует потребительские предпочтения в отношении конкретных марок товаров в зависимости от их географического расположения [6]) для исследования дифференциальных эффектов ИТ в управлении соотношением затрат и выручки. В исследовании использовались наблюдения за 68 банками США на протяжении 20 лет. В своем заключении авторы утверждают, что использование ИТ, в том числе для управления взаимоотношениями с клиентами, в банках приводит к снижению затрат на заработные платы, повышает долю рынка, а также выручку и прибыль. Данное исследование ценно для понимания общего влияния ИТ на банковскую деятельность. Однако, применять дедукцию и утверждать, что это справедливо для каждого отдельного банка, не корректно.
Понимая значимость CRM-системы в банке, представители бизнеса не экономят на проектах по их внедрению и нанимают экспертов по автоматизации для составления функциональных и технических требований. При внедрении CRM-системы банк рассчитывает на эффект синергии, который выражается в повышении объема прибыли, уменьшении транзакционных издержек и потери информации. Также, ожидается формирование качественной и оптимальной клиентской базы при относительно невысоких затратах на внедрение и эксплуатацию системы. Обычно оценить экономические выгоды от внедрения CRM-систем и эффективность этого проекта бывает достаточно сложно. Одной из причин являются временные рамки: период внедрения проекта может растянуться не на один год, особенно в крупных банках, где продукты обладают сложной диверсификацией, а процессы - высокой вариативностью. В целом, процесс внедрения CRM-системы и синхронизация её с уже имеющейся ИТ-архитектурой имеет множество рисков и проблем, которые ИТ-специалистам необходимо учитывать. Следует отметить, что по оценкам экспертов доля неуспешных CRM-проектов варьируется от 20 до 50%. Поэтому, во избежание риска, при принятии решения о внедрении банковской CRM-системы учитывают несколько групп индикаторов для оценки критичности системы для бизнеса:
· планирование и бюджет;
· функциональные требования;
· качество данных;
· внешние факторы;
· человеческий фактор;
· инциденты.
На основании индикаторов каждой из этих групп возможно определить возникающие риски и сформулировать возможные причин неуспешного внедрения проекта. В части минимизации рисков, связанных с планированием и бюджетом, CRM-стратегии позволяют банку сделать оправданный выбор среди существующих систем и платформ, определить возможные отклонения от бюджета и тщательно спланировать расписание проекта. В настоящее время есть возможность выбора CRM системы в зависимости от специфики работ банка: решения под ключ (коробочные), полностью кастомизированные системы, коробочные решения с возможностью дополнительных настроек. Готовые решения для банковского сектора, процессы в которых построены на лучших практиках и референтных моделях, такие как Seibel CRM, SalesLogix, Oracle CRM, Microsoft Dynamics CRM, Terrasoft CRM, Naumen CRM, - самые предпочтительные. При выборе CRM решения вероятность выбора одной из этих систем довольно высока, потому что эти системы можно использовать без кардинальных изменений банковских процессов. С другой стороны, если банк не имеет собственной CRM-стратегии, он не сможет оценить все преимущества готового решения и вообще рискует выбрать неподходящую для своего бизнеса систему [7].
Однако, даже имея хорошо продуманную и формализованную CRM-стратегию, банк может столкнуться с техническими и архитектурными сложностями при ее внедрении, потому что зачастую систему приходится адаптировать под имеющуюся ИТ-архитектуру, либо модифицировать ИТ-архитектуру для того, чтобы CRM-система влилась в ансамбль систем и приносила наибольшую выгоду.
О том, как системное окружение в банке влияет на его деятельность и какие есть выгоды от его эксплуатации, можно прочитать во многих источниках, но как построить системную архитектуру, способную максимально полно покрывать бизнес потребности и при этом не являться крупнейшей статьёй затрат, понять гораздо сложнее. Как правило, банковские системы, как и любой другой класс систем, нуждаются в переработках. Некоторые из этих доработок являются неизбежными, например, меняются бизнес-правила, появляются новые правовые регуляторы или внедряется новое приложение, несовместимое с уже имеющимися. Принимая решение о необходимости доработки, ИТ-специалисты зачастую осознают, что ее можно было бы избежать, если бы в момент внедрения нецелевого функционала решение было бы спроектировано иначе с системной точки зрения. Притом в большинстве случаев, с точки зрения бизнеса, функционал полностью соответствует потребности, однако архитектурно он реализован не оптимально. Например, он затрудняет последующую доработку, работает с задержками или потребляет слишком много вычислительных ресурсов. Системные аналитики и разработчики в таком случае прибегают к особым доработкам, не имеющим прямой бизнес-ценности. Код системы изменяется так, чтобы с точки зрения UX этого было не заметно. Подобное изменение системы называется рефакторингом, и является одним из инструментом повышения качества системного кода и работоспособности приложения [8].
Рефакторинг - это процесс изменения программного обеспечения таким образом, что внешнее поведение системы для пользователя остается неизменным, однако внутренняя структура становится более оптимальной. Это способ привести код системы в порядок, который существенно снижает вероятность появления системных ошибок [9]. Без рефакторинга системное решение рано или поздно перестает удовлетворять системных архитекторов и разработчиков, а разработка нового функционала без внесения изменений в имеющийся код ведет к ряду негативных последствий. Как правило, оценить негативные последствия заранее не представляется возможным, либо такие оценки носят прогностический характер. Однако, есть ряд исследований, основанных на статистических данных, которые приводят к выводу, что между рефакторингом и качеством системы есть корреляция. Например, в исследовании, опубликованном в «International Journal of Software Engineering & Applications», под названием «An Empirical Evaluation of Impact of Refactoring on Internal and External Measures of Code Quality» авторы ставят цель доказать либо опровергнуть, что рефакторинг повышает качество системы [10]. Они проводят оценку нескольких техник, используемых для переработки кода: ввод локальных расширений, отслеживание дублирования данных, замена типового кода наследуемыми классами, замена условий полиморфизмом, введение нулевых объектов, выделение наследуемых классов, выделение интерфейсов, метод шаблонных форм. Среди метрик, по которым отслеживается эффект рефакторинга, они выделяют внешние (способность системы к быстрым изменениям, ее анализируемость) и внутренние (использование вычислительных мощностей, время отклика системы). Далее проводятся вычисления и анализ для подтверждения или опровержения заявленных гипотез. Результаты показывают, что ни одна из нижеперечисленных гипотез не может быть отвергнута:
H1: анализируемость системы после рефакторинга кода выше, чем до рефакторинга;
H2: способность к изменениям у системы выше после рефакторинга;
H3: время отклика система после рефакторинга выше;
H4: эффективность использования вычислительных мощностей выше для системы после рефакторинга кода.
Таким образом, авторы доказывают целесообразность рефакторинга и его положительный эффект на качество системы по всем выбранным метрикам.
К аналогичным умозаключениям приходят и авторы исследования «A Case Study of Refactoring Large-Scale Industrial Systems to Efficiently Improve Source Code Quality», в котором они рассмотривают эмпирические данные более 100 рефакторных патчей для 5 разных систем, содержащих более 5 миллионов строк кода [11]. По результатам их исследования, даже массивный рефакторинг, способный нарушить архитектуру системы, всё-таки оказывается эффективным, а риски переработок - оправданными.
Как правило, внедряя определенный функционал, не всегда сразу заранее очевидно, что в нем придется менять внутреннюю логику. Есть некоторые индикаторы, которые позволяют понять, что рефакторинг неизбежен. Об одном из случаев неизбежного рефакторинга пишут авторы статьи «A True Story of Refactoring a Large Oracle PL/SQL». В статье описан случай, когда системный код вышел из-под контроля, и компании пришлось остановить разработку бизнес-требований и задействовать все ресурсы в рефакторинге [12]. Причиной проблемного кода стала передача разработки на аутсорсинг нескольким вендорам, каждый из которых разрабатывал функционал в своем стиле. Асинхронность разработки выявила признаки необходимости рефакторинга:
· только несколько опытных разработчиков понимали полностью архитектуру приложения;
· увеличилась стоимость модификаций системы;
· оценка доработок стала неточной;
· ухудшилось качество системного кода;
· поддержка системы стала дороже;
· тестирование новых доработок стало дороже.
Процесс рефакторинга включал в себя избавление от ряда ненужных хранимых процедур, переход на переиспользование кода, удаление ненужных данный, переход на новую структуру хранения данных. В заключении авторы утверждают, что рефакторинг привел к повышению качество системы и не позволил бизнесу замедлиться.
Таким образом, обзор публикаций на тему значимости CRM систем и в банковской деятельности приводит к выводу, что данный класс систем действительно является фундаментальным, и без него не представляется функционирование банка как клиентоориентированной организации. В приведенных статьях разные авторы с помощью эмпирических и количественных методов приходят к аналогичным умозаключениям о том, что качество CRM-систем коррелирует с лояльностью клиентов и прибылью банка. В целом, проблема значимости CRM-систем в бизнесе, и в частности в банках, широко освещена в публикациях как зарубежных авторов, так и российских. В отличие от этого, проблема значимости рефакторинга для бизнеса не имеет достаточного раскрытия в статьях, поскольку в основном статьи о рефакторинге носят технический характера и направлены на исследование и сравнение инструментов рефакторинга. Тем не менее, авторы этих статей хоть и не утверждают напрямую о ценности доработок для бизнеса, все сходятся во мнении, что подобные системные изменения положительно влияют на качество систем, поэтому актуальность заявленной проблемы подтверждается. Кроме того, отсутствие исследования на тему оценки целесообразности доработок при понимании их необходимости говорит о новизне данного исследования, практическая значимость которого будет раскрыта в последующих главах.
2. Особенности платформы Pega
Платформа Pega - это один из продуктов компании Pegasystems, американской компании, создающей программное обеспечение с 1983 года. Компания была основана Аланом Трефлером в Массачусетсе, и в первые годы своего существования была сфокусирована преимущественно на создании систем для управления делами, в частности для компании American Express.
Компания стала публичной в 1996 году и начала торговать ценными бумагами на американской фондовой бирже NASDAQ под названием Pega. Собрав несколько миллионов финансирования на бирже, а также став публичной компанией, Pegasystems освободилась от необходимости привлекать венчурные инвестиции. В марте 2010 года она приобрела другую комапнию по разработке программного обеспечения, Chordiant, за 161,5 миллионов долларов. Приобретение позволило Pegasystems выйти на новые рынки с новыми продуктами для онлайн обучения, телекоммуникаций и здравоохраниения, интегрировав Chordiant в свои процессы в качестве основной CRM-технологии.
В 2012 была представлена Pega Cloud, которая использовала Amazon Web Services, а в 2013 Pegasystems приобрела Antenna Software - разработчика мобильных приложений. В 2014 компания наняла облачных специалистов для разработки стратегии в сфере облачных технологий, а также стала инвестором нескольких облачных проектов в Северной Америке и Индии. В этом же году компания купила небольшой стратап по текстовой аналитике для того, чтобы собирать неструктурированные данные из СМИ, транслировать их в данные и использовать при построении стратегий взаимоотношений с клиентами [13].
Сегодня деятельность компании направлена на разработку и поддержку ориентированного на клиента программного обеспечения. В частности, она специализируется на ПО для управления процессами (BPM) и управления взаимоотношениями с клиентами (CRM) и предлагает на рынке больше заказных решений и технологий, чем ее конкуренты Oracle Corporation и SAP ERP. Главным продуктом Pegasystems является Pega Platform, часть пакета по привлечению клиентов и автоматизации диджитал процессов Pega Infinite, который предназначен для связи пользовательских интерфейсов с приложениями бэк-энда [14].
В Таблице 1 представлены основные продукты Pegasystems по отраслям и приведено их краткое описание. В каждом из этих решений реализованы лучшие практики взаимодействия с клиентами [15].
Таблица 1. Решения Pegasystems по отраслям
|
Отрасль |
Отраслевые решение от Pegasystems |
Описание решения |
|
|
Коммуникации и связь |
· «Pega Retention for Communications» |
Решение предлагает механизмы для удержания клиента, такие как NBA (Next Best Action), облегчая общение с клиентом лицом к лицу в разных каналах коммуникаций. В частности, анализируя склонность клиента к оттоку, оно создает активности онбординга, минимизирует затраты на удержание клиента, уменьшает отток и прогнозирует действия конкурентов в отношении клиентов. |
|
|
· «Pega Customer Service for Communications» |
Решение предназначено для улучшения качество поставки сервисов клиентам. Оно позволяет уменьшить усилия клиента, предоставив им возможность самостоятельного управления услугой на веб-сайте или в мобильном приложении. Данные об активности клиента на сайте и в мобильном приложении позволяют также воспользоваться технологией NBA и предложить последующий шаг в отношении клиента. Решение максимизирует самообслуживание и направляет клиен6та по процессу. Также решение является гибко настраиваемым и позволяет вносить в него быстрые изменения без необходимости писать код и скрывает сложности в работе с наследуемыми системами. |
||
|
· «Pega Fulfillment Control Center» |
Решение позволяет собрать и настроить порядок действий и функций в процессах, повысить прозрачность и измеряемость процессов, ускорить жизненный цикл объектов в процессе, позволяет собрать в одном процессе автоматизированные функции и ручные задачи. |
||
|
Электричество и коммунальные услуги |
· «Pega Marketing» |
Решение позволяет сфокусировать продажи не на том, что компания предлагает, а на спросе, который реально есть у потребителя. Для этого при сегментации клиентов и определения потребностей используются такие технологии, как предиктивный анализ, машинное обучение, обработка устной речи, поддержка принятия решений и комплексный анализ событий. Все собранные данные используются для определения удачного времени продажи или онбординга для клиента, а также для уменьшения вероятности его оттока. |
|
|
· «Pega Field Service» |
Комплексное решение для обслуживания клиентов на месте, позволяющее полностью управлять циклом взаимодействия с клиентом, от приветственного звонка до закрытия с ним сделки. Решение повышает продуктивность полевых сотрудников и уровень удовлетворения клиента. Приложение может быть развернуто на любой мобильной платформе (Android, iOS, Windows). |
||
|
· «Pega Robotic an Automation Intelligence» |
С помощью решения можно автоматизировать ручные, часто повторяющиеся операции и тем самым повысить производительность и скорость протекания процесса. Рассмотрение претензий, онбординг новых клиентов или сотрудников, сверка финансовых показателей или обновление профиля клиента в системной записи и т.д. могут быть оптимизированы за счет этого решения. |
||
|
Финансовые услуги |
· «Pega for Consumer Banking» · «Pega for Corporate & Investment Banking» · «Pega Salesforce Automation» |
Решение содержит в себе комплекс модулей, которые позволяют обеспечивать эффективный маркетинг финансовых услуг, управления взаимоотношениями с клиентами розничного обслуживания и корпоративных лиц, управление жизненным циклом, управление сделками и продажами банковских продуктом от привлечения клиентов из разных каналов до оформления договоров в бэк-офисе. |
|
|
· «Pega for Wealth Management» |
Решение для финансовых советников, позволяющее работать с клиентами высокого сегмента, выстраивать с ними взаимоотношения на основании их личных интересов с применением основных принципов KYC. |
||
|
Производство и высокие технологии |
· «Pega Warranty» |
Решение позволяет направлять гарантийные процессы, управлять процессом клиентских претензий, от составления гарантийного талона до диагностики неисправности продукта и выплаты материальной компенсации. |
Одно из решений категории Финансовые сервисы от Pegasystems - это Pega Sales Automation (SFA), которое является предметом данной магистерской диссертации. Ранее оно называлось Pega Sales Force Automation, но было переименовано во избежание путаницы с продуктами другого американского производителя CRM систем Salesforce.
Решение включает в себя возможности использования искусственного интеллекта, методы управляемых продаж, мобильную версия для ведения продаж «в полях», интеграцию c корпоративными мессенджерами, комплексную автоматизацию процессов для повышения эффективности менеджеров по продажам, Единую СРМ для интеграции различных клиентских приложений, облачные решения [16].
Например, в нем реализован предиктивный анализ сделок. С помощью искусственного интеллекта предиктивные модели предсказывают вероятность перехода сделки на следующий шаг, вероятность успешного закрытия сделки или риск отказа клиента от сделки на определенном шаге. Предиктивный анализ основан на текущих активностях по продажам и исторически сложившимся эталонам (benchmarks) в сделках похожего типа. В Приложении 1 представлена аналитическая карточка сделки (Opportunity Insight), на которой видны:
1) Процесс (flow) сделки: сделка находится на шаге «Определение» (Qualification)
2) Вероятность перехода сделки на стадию Анализ (Analysis) с комментарием, сколько в среднем сделок переходят на этот шаг
3) Вероятность успешного закрытия сделки с комментарием, сколько в среднем сделок закрываются успешно
4) Прогноз по дате закрытия сделки: прогнозируемая дата закрытия сделки (Predicted Qtr) больше, чем запланированная дата закрытия (Targret) и, как следствие, предполагаемый статус сделки = Delayed
5) Последующие рекомендованные действия в отношении клиента или для менеджера: Предложить расширение условий контракта, Прикрепить к сделке данные по продукту за 10 лет, Прочитать конкурентную карту от Salesforce
6) Строку с вкладками, содержащими доп. информацию по сделке: Контакты, Активности, Лиды и т.д.
Также для менеджеров по продажам есть инструменты отслеживания их плана продаж и прогнозы относительно их попадания в квоту. На Рисунке 1 представлен виджет с дашборда «Sales Futurecast», который на основании интеллектуального анализа предсказывает, сможет ли менеджер выдержать квоту продаж в текущем квартале. Менеджер, при непопадании в квоту, должен скорректировать свои планы и стратегии продаж.
Рисунок 1. Виджет для менеджера по продажам «Sales Futurecast»
В Приложении 2 изображен другой виджет для менеджеров по продажам, использующий адаптивную модель оценки лидов, которая позволяет менеджерам приоритезировать лиды. Лиды в списке имеют ранг (1-100), который вычисляется системно на основании 19 метрик, включающих в себя информацию о лиде, организации, контактном лице и данные о менеджере по продажам. Наиболее весомые параметры, влияющие на ранг лида - это Источник лида (Source), Рейтинг (Rating, холодный/горячий) и среднее время до конвертации. Кроме анализа лидов, в системе реализованы интеллектуальные инструменты работы с имеющимися активными клиентами. Один их таких механизмов - Next Best Action (NBA) - аналитический инструмент, позволяющий с помощью предиктивных моделей предлагать наилучшее действие в отношении того или иного клиента. Рекомендации составлены по профилю и истории клиента и позволяют предложить клиенту продукт с наивысшей вероятностью оформления [17]. В Приложении 3 представлен дашборд менеджера по продажам с выделенным виджетом NBA, который показывает рекоменджуемые действия в отношении клиентов - физических лиц. Такой подход, основанный на глубокой аналитике клиентских данных, позволяет повысить продажи не только за счет предложения наиболее удачного продукта клиенту, но и за счет кросс-блочности приложения. Кросс-блочность приложения состоит в ведении процессов по физическим и юридическим лицам всех сегментов в одном приложении, что означает использование общих данных и позволяет, например, привлекать клиентов - физических лиц, владеющих компаниями, на корпоративное обслуживание. Таким образом, способности Единой CRM системы привлекать клиентов на всевозможные продукты колоссальны [18].
Поскольку Pega Sales Automation - одно из наиболее тиражируемых решений Pegasystems, оно было взято за основу сравнительного анализа, проведенного в 2018 году исследовательской и консалтинговой компанией Gartner. В исследовании были рассмотрены основные системы известных вендоров, используемые для процесса привлечения клиентов (Customer Engagement). Результатом исследование было расположение вендоров в так называемом Магическом Квадранте (Рисунок 2). Это один из инструментов Gartner, который используется для оценки поставщиков какого-либо сегмента рынка ИТ. В нем использованы две экспертные прогрессивные шкалы: «способность реализации» (англ. ability to execute) и «полнота видения» (completeness of vision). Каждый поставщик оценивается по этим двум критериям и попаадает в один из четырех квардантов плоскости:
* «лидеры» (leaders) -- поставщики с положительными оценками по «полноте видения» и по «способности реализации»,
* «претенденты» (сhallengers) -- поставщики с положительными оценками только по «способности реализации»,
* «провидцы» (visionaries) -- поставщики с положительными оценками только по «полноте видения»,
* «нишевые игроки» (niche players) -- поставщики с отрицательными оценками по обоим критериям [19].
Рисунок 2. Магический квадрант Gartner по привлечению клиентов
Две метрики, по которым были даны экспертные оценки вендорам, являлись собирательными и включали в себя оценки по следующим аспектам СRM-систем, представленным в Таблице 2.
Таблица 2. Критерии для метрик Магического квадранта
|
Критерий |
Значимость критерия |
|
|
Полнота видения |
||
|
Продукт или сервис |
High |
|
|
Общая жизнеспособность система |
Medium |
|
|
Выполнение продаж / Ценообразование |
High |
|
|
Реакция на изменение рынка |
High |
|
|
Маркетинг |
High |
|
|
Опыт клиентов |
Medium |
|
|
Операционная деятельность |
Medium |
|
|
Cпособность реализации |
||
|
Понимание рынка |
Medium |
|
|
Маркетинговая стратегия |
High |
|
|
Стратегия продаж |
High |
|
|
Продуктовая стратегия |
High |
|
|
Бизнес-модель |
Medium |
|
|
Инновации |
Medium |
|
|
География системы |
Medium |
Таким образом, по результатам исследования влиятельного агентства Gartner, вендор Pegasystems с решением SFA занимает квадрант «лидеров» вместе с такими сильными конкурентами, как Microsoft, Oracle и Salesforce. Данное исследование, а также оценки экспертов и архитекторов Альфа-Банка, стали аргументами в пользу выбора коробочного решения Pega Sales Automation для построения Единой CRM Банка - Pega SFA, функционал и кастомизация которого будут рассмотрены в следующей главе.
З. Анализ временных решений в Pega SFA
Pega SFA в Альфа-Банке
В данной магистерской диссертации рассмотрен кастомизированный функционал Единой CRM системы, построенной на платформе Pega на основе коробочного решения «Pega Salesforce Automation» (далее Pega SFA) для Альфа-Банка.
Альфа-Банк является универсальным банком, осуществляющим все основные виды банковских операций, представленных на рынке финансовых услуг, включая обслуживание частных и корпоративных клиентов, инвестиционный банковский бизнес, торговое финансирование и управление активами. В Альфа-Банке обслуживается более 45 тыс. корпоративных клиентов и более 2,4 млн. физических лиц. Кредитование -- один из наиболее важных продуктов, предлагаемых Банком корпоративным клиентам и предмет стратегии развития. Кредитная деятельность Альфа-Банка включает торговое кредитование, кредитование оборотного капитала и капитальных вложений, торговое и проектное финансирование. Среди клиентов Банка есть крупные предприятия, при этом основные заемщики -- предприятия среднего бизнеса. Альфа-Банк диверсифицирует свой кредитный портфель, последовательно снижая его концентрацию. Альфа-Банк создал разветвленную филиальную сеть -- важнейший канал распространения услуг и продуктов. Также Банк держит фокус на оформление зарплатных проектов и увеличение их доли в продажах и развитие партнерских про грамм - привлечение других ЮЛ и ФЛ на агентские договоры. Кроме того, согласно недавно презентованной стратегии развития до 2021 года, Банк создает концепцию первого в России безбумажного банка, который в целевой картине мира отойдет от бумаг в отделениях и и бэк-офисе: везде, где это не является требованием законодательства или клиентов. Это будет достигнуто за счет цифровизации процессов, поэтому развитие Единой CRM для бизнеса необходимо [20].
Подразделение, в компетенции которого находится разработка Единой CRM системы - Центр компетенций SFA - занимается автоматизацией работы менеджеров розничного и корпоративного блоков. В частности, команды разработки центра компетенций SFA обслуживают 3 основные направления - РБ (розничный бизнес, продукты для физических лиц), МСКБ (малый, средний корпоративный бизнес, продукты для юридических лиц низкого и среднего сегментов и ККБ (крупный корпоративный бизнес). В данной магистерской диссертации рассмотрен функционал блока МСКБ, ответственного за проектирование и разработку функционала продажи кредитных продуктов (различные виды кредитов, овердрафты, лизинг, факторинг), депозиты, расчетно-кассовое обслуживание, партнерские программы, зарплатные проекты. Также, в ответственности блока МСКБ находится построение процесса онлайн-дистрибуции банка (прием и обработка заявок из различных каналов на разные продукты) и создание функционала для партнерских менеджеров (портфель партнеров, перезакрепление партнеров за другими менеджерами). Система является одной из крупнейших систем Банка, имеет интеграции с более, чем 17 ключевыми системами (Диаграмма взаимодействий SFA c другими системами Банка представлена в Приложении 4). Реестр взаимодействия с другими системами и их краткое описание представлены в Таблице 3.
Таблица 3. Реестр взаимодействий систем с SFA
|
Система Банка |
Роль Sales CRM |
Протокол |
Через ESB? |
Описание |
|
|
MDM(L) |
Потребитель |
SOAP |
Нет |
Клиенты, связи, базис коммуникаций, продуктовый базис, портфель клиентов. |
|
|
MDM(I) |
Потребитель |
SOAP |
Да |
||
|
EQ |
Потребитель |
SOAP |
Да |
АБС |
|
|
OCRM |
Потребитель |
SOAP |
Да |
Система управления коммуникациями и маркетинговыми компаниями |
|
|
Claim CRM |
Потребитель |
SOAP |
Да |
Система по работе с претензиями клиентов |
|
|
OBIP |
Потребитель |
SOAP |
Нет |
Преобразование бизнес-данных и код шаблона в получаем печатную форму в PDF |
|
|
Unified Front |
Потребитель |
REST |
Нет |
Единое окно (общий UI систем) |
|
|
Unified Front |
Потребитель |
UI |
Нет |
Переход из Sales CRM в Unified Front через отрытие страниц (Open URL in window) для сделок по бондам и отчетами в инвест портфеле; для интеграции используется токен авторизации оператора Sales CRM в Unified Front'е |
|
|
Alfa Direct |
Потребитель |
REST |
Нет |
Витрина сделок с брокерских счетов, система для торговли бондами |
|
|
WBI |
Потребитель |
JMS |
Нет |
Sales CRM публикует бизнес-события. |
|
|
DWH |
Потребитель |
db-link |
Нет |
Витрина данных |
|
|
DWH RB |
Потребитель |
db-link |
Нет |
Витрина данных для блока Розничный бизнес |
|
|
CRM BMB |
Потребитель |
UI |
Нет |
Старая CRM-система под вывод |
|
|
Lotus Notes |
Потребитель |
SOAP |
Нет |
Создание и чтение календарей сотрудников, почтовый сервис |
|
|
Почтовый сервер |
Потребитель |
SMTP |
Нет |
Отправка писем клиентам |
|
|
AD |
Потребитель |
LDAP |
Нет |
Аутентификация и авторизация пользователей |
Архитектура Pega SFA
Архитектура системы поделена на компоненты - функциональные модули, инкапсулирующие в себе определенную логику и набор функций, необходимых для выполнения задач разных бизнес-направлений. Список функциональных компонентов с оценкой и кратким описанием представлен в Таблице 4. Оценка компонентов составлена на основании экспертных оценок архитекторов Банка и отражает количество строк кода, сложность доработок и степени влияния на другие компоненты.
Таблица 4. Компоненты SFA
|
№ |
Компонент |
Описание |
Оценка |
|
|
1 |
Поиск клиента |
Поиск карточек клиента ЮЛ и ФЛ в мастер-системе MDM по клиентским контактным данным |
S |
|
|
2 |
Портфель менеджера/отделения |
Представление для менеджеров (клиентских менеджеров привлечения и развития, сотрудников отделений) для работы с карточками клиентов с настраиваемыми фильтрами |
L |
|
|
3 |
Карточка клиента |
Карточка клиента ЮЛ или ФЛ, механизмы ее создания и редактирования, отображение связей клиента с менеджерами, продуктами. Информация об аффилированных компаниях/лицах, маркеры активности и комплаенс-скорингов. |
XL |
|
|
4 |
Связи клиента |
Связи клиента с другими компаниями/лицами |
S |
|
|
5 |
Лидогенерация |
Создание и передача лидов по всевозможным каналам, назначение лидлв на корзины и сотрудников, конвертация лидов в проспекты и сделки |
L |
|
|
6 |
Мультитаск |
Коммуникации с клиентами (назначение звонков, встреч), управление корреспонденцией, управление личной очередью задач менеджеров |
M |
|
|
7 |
Продажи (сделки) |
Процессы продаж для каждого отдельного продукта с учетом специфики процессов |
XL |
|
|
8 |
Онбординг |
Проведение активностей, направленных на удержание вновь привлеченных клиентов |
M |
|
|
9 |
Дашборд |
Набор виджетов «Доска лидеров», «Задачи на сегодня», «Заявки», «Мой рейтинг», «Мотивация», «Воронка продаж» |
S |
|
|
10 |
Продкаталог |
Каталог по продуктам РБ и МСКБ |
S |
|
|
11 |
Опросники |
Voice of client: сбор обратной связи от клиентов |
S |
|
|
12 |
Перезакрепление |
Передача клиентов между клиентскими менеджерами привлечения и развития и партнерскими менеджерами |
M |
|
|
13 |
Приложение Compliance |
Проверка клиентов на соответствие требованиям Банка и СЭБ |
S |
|
|
14 |
Приложение Motivation |
Расчет мотивационных выплат сотрудникам за проведенные сделки |
XL |
|
|
16 |
Приложение CRM BMB |
Поддержка старой CRM-системы для блока МБ |
M |
|
|
17 |
Орг. структура |
Иерархия сотрудников и их принадлежность к подразделениям |
M |
|
|
20 |
Отчёты |
Отчеты BI в различных срезах |
S |
|
|
21 |
Онлайн заявка |
Заявки из различных каналов привлечения на все банковские продукты, их обработка разными сотрудниками |
XL |
Описание доработок с последующим рефакторингом
В данном разделе будут описаны 3 доработки, касающиеся одного из самых сложных процессов Банка - процесс онлайн-дистрибуции. Этот процесс, релизованный в SFA, заключается в приеме заявок из разных каналов (сайт, мобильные и веб приложения, посадочные страницы, партнерские программы) на различные продукты для юридических лиц. Заявки маршрутизируются разным исполнителям и обрабатываются по разным процессам в зависимости от многих параметров, таких как статус клиента, канал поступления заявки, продукт, сегмент и т.д. Схема процесса онлайн-дистрибуции представлена в Приложении 5.
Для анализа доработок выбран именно этот процесс, поскольку он затрагивает наиболее значимые компоненты - Онлайн заявка и Сделки (см. Таблицу 4), поэтому на их примере можно будет более явно проследить эффект от внедрения и последствия от рефакторинга.
1) Интеграция с сервисом управления заявок в процессе онлайн-дистрибуции
При проектировании процесса Онлайн-дистрибуции параллельно велась разработка в нескольких системах, в т.ч. SFA и Сервисе управления заявками (СУЗ) - мастер-системе по заявкам, принимающей их из внешних источников. В целевом варианте СУЗ интегрируется с SFA с помощью веб-сервисов (REST-протокол) через шину, по схеме СУЗ - ESB - SFA и передает необходимые параметры, с которыми должен быть вызван сервис SFA по созданию заявки.
На момент разработки механизма создания сущности заявки в SFA на основании данных, полученных из СУЗа в .json файле, интеграция между этими системами не была реализована. Поэтому было принято решение разработать временный механизм - activity CreateOrder - эмулирующий интеграцию с СУЗом и создающий сущность заявки в SFA с вручную введенными параметрами.
Поскольку на момент начала разработки уже была понятна концепция UI онлайн-заявки (целевой UI представлен в Приложении 6, пример нецелевого UI на момент использования activity LeadOrder не сохранился), набор входных параметров в activity для создания сущности заявки был определен, как показано в Таблице 5 (выгрузка параметров activity из среды разработки - Pega Designer Studio).
Таблица 5. Параметры activity CreateOrder из Pega Designer Studio
|
Name Наименование параметра) |
Data type (Тип данных) |
Required (обязательность заполнния |
Description (Описание) |
|
|
OrderType |
String |
Обязательное |
Поле "Тип заявки", также тема связанной коммуникации |
|
|
PartnerName |
String |
Не обязательное |
Поле "Имя партнера" |
|
|
PARTNERPINEQ |
String |
Не обязательное |
PinEQ партнера |
|
|
ToDo |
String |
Не обязательное |
Поле "Что сделать" |
|
|
SP |
String |
Не обязательное |
Поле "Спецпредложение" |
|
|
ContactName |
String |
Не обязательное |
ФИО Контактного лица |
|
|
MobilePhone1 |
String |
Не обязательное |
Поле "Телефон" |
|
|
MobilePhone2 |
String |
Не обязательное |
Поле "Телефон" |
|
|
TIN |
String |
Не обязательное |
ИНН |
|
|
Name |
String |
Не обязательное |
Именование компании |
|
|
CityFiasCode |
String |
Не обязательное |
Код города по ФИАС (ключ МДМ, префикс "Fias_") |
|
|
Comment |
String |
Не обязательное |
Комментарий к Заявке |
|
|
Revenue |
String |
Не обязательное |
Обороты |
|
|
OrderSource |
String |
Не обязательное |
Откуда клиент узнал о Банке |
|
|
TypeOfActivity |
String |
Не обязательное |
Вид деятельности |
На первых этапах механизм запускался напрямую из Pega Designer Studio, где с помощью простого графического интерфейса вводились параметры для создания в БД сущности заявки без интеграции. После того, как интеграция с СУЗом была разработана, пришлось проводить рефакторинг: отключать данный механизм и переходить на полноценную интеграцию через веб-сервис .json-запросом. При переходе на целевое решение команда столкнулась с проблемой приведения типов данных: во временном решении большинство данных имело тип string (см. Таблицу 5), поскольку было непонятно, в каком виде СУЗ будет присылать данные. В целевом решении часть этих данных осталась строковыми, а у других поменялся тип (например, обороты стало численным типом).
На момент принятия решения о разработке activity, перед командой стояла еще одна альтернатива: разработка SOAP веб-сервиса заранее, который потом вызывался бы системой СУЗ с необходимыми параметрами для создания заявки. До реализации целевой интеграции можно было бы вручную вызывать сервис из приложения SOAP UI. Однако, от этой альтернативы отказались, поскольку не было уверенности в том, что сообщения будут приходить в .xml-формате (в итоге в целевом варианте договорились реализовать REST-сервисы, интеграция происходит .json-сообщениями), а также по причине, описанной выше - непонимание формата входящих данных.
Разработка механизма для эмуляции интеграции заняла у команды 1 спринт (2 недели) с учетом аналитики, разработки и тестирования. Целевая интеграция с СУЗом появилась через 2 месяца. На исправление ошибок с приведением типом ушло еще 5 рабочих дней. Таким образом, рабочая целевая интеграция появилась через 4,5 спринта (9 недель). Потратив 1 спринт на нецелевой механизм, который заранее был запланирован под вывод после внедрения основной интеграции, команда получила возможность не ждать готовности смежной системы и, не теряя времени, разрабатывать функционал заявок. За 2 месяца использование нецелевого варианта командами проекта SFA было разработано и выведено на прелайв (предбоевой стенд) еще 15 задач. В данном кейсе, осознанно реализовав решение под последующий вывод, команда выигр...
Подобные документы
Сущность процессов слияния и поглощения в банковском секторе, правовое поле данного вида сделок. Анализ финансового состояния и оценки рыночной стоимости ВТБ Групп и Банка Москвы до поглощения. Пути совершенствования этих процессов в современных условиях.
дипломная работа [2,1 M], добавлен 18.06.2013Понятие иностранного капитала в банковском секторе. Негативные последствия влияния иностранного капитала на банковский сектор России. Инструмент квотирования присутствия иностранных банков в России. Риск сравнительной потери деловой репутации банка.
курсовая работа [41,5 K], добавлен 15.05.2013Общая классификация банковских рисков, модели кредитного и рыночного риска. Оценка моделей определения рисков. Влияние макроэкономических переменных на показатели устойчивости банка. Перспективы применения эконометрических методов в банковском секторе.
дипломная работа [774,7 K], добавлен 19.11.2017Основная миссия АО "Банка развития Казахстана" на рынке банковских услуг, законодательные основы его деятельности. Анализ деятельности банка по финансированию инвестиционных проектов. Исследование влияния реализованных проектов на национальную экономику.
курсовая работа [1,5 M], добавлен 01.02.2013Современное состояние банковской системы России, направления ее развития. Особенности электронного дистанционного сервиса в российских банках. Инновационное применение системы виртуальных платежей, пластиковых и магнитных карточек в банковском секторе.
курсовая работа [83,2 K], добавлен 08.10.2010Формирование резервов на возможные потери по ссудам. Апробирование испанской модели динамического резервирования на российском банковском секторе. Авторская модель повышения стабильности банковской системы в условиях макроэкономической дестабилизации.
дипломная работа [1,2 M], добавлен 08.11.2015Основные подходы к определению понятия финансовой стабильности, анализ главных показателей ее оценки в банковском секторе. Анализ мер Банка России по преодолению финансовой нестабильности во время и после кризиса, мероприятия по повышению устойчивости.
дипломная работа [1,5 M], добавлен 27.04.2016Понятие, сущность и виды конкуренции в банковском секторе, факторы и показатели. Структура российского рынка розничных банковских продуктов, его компоненты: ипотечное и автокредитование, кредитных карт. Динамика количества банковских учреждений.
курсовая работа [1,4 M], добавлен 18.06.2015Тенденции на рынке M and A-сделок. Мотивы слияний и поглощений в банковском секторе. Основные факторы активизации банковских слияний и поглощений. Специфика российских слияний и поглощений в банковском секторе. Экспансия иностранных банков.
реферат [22,0 K], добавлен 09.12.2006Кризисные явления в банковском секторе, их сущность, типы, формы. Влияние кризисных явлений в экономике на состояние и развитие банковских систем. Воздействие мировых финансовых кризисов на банковскую систему РФ. Последствия банковского кризиса в России.
курсовая работа [201,3 K], добавлен 02.09.2014Понятие рыночной дисциплины в банковском секторе. Рыночная дисциплина условиях экономического кризиса. Чувствительность вкладчиков к рискам банка на примере японского рынка вкладов физических лиц. Основные причины и последствиях долларизации вкладов.
дипломная работа [2,5 M], добавлен 02.10.2016Сущность, формы и функции кредита. Участники, инструменты и основные схемы рынка потребительского кредитования. Перспективы его развития. Объемы кредитования физических лиц в банковском секторе РФ. Оценка операционных рисков и кредитного портфеля банка.
дипломная работа [618,4 K], добавлен 08.12.2014Характеристика АО "БЦК" на банковском рынке Казахстана. Изучение операций с ценными бумагами, как вида инвестиционной деятельности банка. Методы оценки пруденциальных нормативов и финансовых показателей банка, анализ моделей портфельного инвестирования.
курсовая работа [783,7 K], добавлен 09.03.2010Экономические основы осуществления финансовой оценки устойчивости коммерческого банка. Показатели надежности банка. Оценка балансовых показателей деятельности, пассивов и активов. Направления совершенствования оценки устойчивости коммерческого банка.
дипломная работа [152,1 K], добавлен 25.12.2012Анализ современного состояния банковской системы и путей ее совершенствования. Политика валютных интервенций Банка России, особенности, отличающие его от многих других стран. Меры по усовершенствованию эффективности проведения банковского надзора.
курсовая работа [509,6 K], добавлен 30.01.2014Понятие активных операций и их экономическое содержание. Измерение активов банка по рыночной стоимости. Факторы роста активов в банковском секторе и в отдельных кредитных организациях. Современное состояние активов российских коммерческих банков.
курсовая работа [215,5 K], добавлен 02.01.2018Понятие ликвидности кредитных организаций. Моделирование эффективной формы регулирования риска путем внедрения в политику кредитора последней инстанции механизма ценообразования помощи со стороны Центрального Банка. Риск ликвидности в банковском секторе.
реферат [208,1 K], добавлен 31.12.2016Прикладное значение бизнес-аналитики, как инструмента обработки информационных массивов, в функционировании банка, уменьшении материальных затрат на работу с данными. Выполнение расчетов ликвидности, дебиторской задолженности, рентабельности активов.
статья [34,2 K], добавлен 19.12.2016Проблемы оценки и снижения рисков в деятельности коммерческих банков. Внедрение скоринг-модели оценки кредитоспособности клиентов банка. Увеличение ресурсов за счет создания нового депозита "Успех". Выдача кредитов под обеспечение ценными бумагами.
дипломная работа [1,2 M], добавлен 21.01.2015Исследования влияния сделок по слияниям и поглощениям на доходность банков через анализ финансовой отчётности. Ожидаемые изменения показателя прибыли банка на основе исторического анализа изменения среднего уровня прибыли для рынка и других переменных.
контрольная работа [30,6 K], добавлен 27.12.2016
