Google+
Журнал Плас Плас Журнал http://www.plusworld.ru/
ул. Кржижановского, д. 29, корп. 5 Москва, 117218 Россия
+7 495 961 1065 http://www.plusworld.ru/upload/templates/logo_plus_ru.png
RSS RSS RSS RSS

Современная розничная система банка: что делает ее такой?

(Нет голосов)

04.06.2007 Количество просмотров 1283 просмотра

Сергей Добриднюк, зам. директора бизнес-направления "Розничное обслуживание" компании "Диасофт"
Успехи развития российского банковского розничного бизнеса в 2006г. с полным основанием можно назвать грандиозными. Объемы потребительского кредитования вновь увеличились вдвое, достигнув более 2 трлн. рублей, а совокупный объем привлеченных средств вырос до 3,4 трлн. рублей, что свидетельствует о высоком потенциале как самих российских банков, так и отечественного рынка финансовых услуг для физических лиц.

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

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

Методологическая проработка банковских продуктов

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

Для массового же клиента банк, анализируя клиентские сегменты, конструирует и выводит на рынок стандартные банковские продукты в определенных комбинациях. Методика разработки массовых продуктов требует от банка определенной зрелости и дальновидности, поскольку она должна учитывать не только текущее состояние дел, но и долгосрочные перспективы развития его бизнеса. При этом нельзя забывать и «первое правило» ритейлового продукта и разработки ПО для его автоматизации: «Если какое-либо свойство продукта, его параметр или услуга не были определены при заведении продукта в систему, то эту функцию нельзя будет выполнить ни при каких обстоятельствах». Фактически при дальнейшем развитии продукта будет запрещено все, что не было описано и просчитано на дату старта продукта.

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

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

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

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

Однако оптимальный путь решения данной задачи – воспользоваться опытом компании-разработчика, поскольку предлагаемое для автоматизации ритейла ПО обычно базируется на четких концепциях. И появление нового функционала обычно сопровождается подробным бизнесописанием конкретной задачи.

Можно признать, что в 2007г. работать с розницей, не имея методолога, становится просто невозможным. Попытки развиваться реактивным способом – «давайте запустим хоть какой-то банковский продукт, а потом посмотрим, что получится» – заканчиваются зачастую плачевно. Вспомним фразу легендарного конструктора С. П. Королева: «Если вы сделаете дело быстро и плохо, люди забудут, что вы сделали быстро, и запомнят, что вы сделали плохо».

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

Модульная архитектура розничного решения

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

Такой метод реализации программы является сегодня достаточно популярным, поскольку позволяет минимизировать издержки, связанные с обменом данными между объектами, достичь высокого качества продукта с предсказуемым результатом написания последней. Наконец, рынок труда программистов, способных написать ПО в рамках данной технологии, сегодня достаточно насыщен.

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

Возникает «эффект домино» – появляющаяся в этом монолите новая функциональность требует перетестирования всех связанных с ней подсистем и – как результат – совершенно непропорциональных затрат временных ресурсов на собственно создание новой программной функции и на полномасштабное тестирование программы в целом.

Ситуацию могут усугубить отсутствие четких границ при создании функциональности (особенно при разработке классическим «водопадным» способом). При этом срок выпуска стабильного программного продукта будет сдвинут на месяцы и даже годы. Что, как нетрудно догадаться, совершенно не устраивает бизнес-подразделения банка.

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

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

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

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

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

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

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

Для выведения нового банковского продукта на рынок могут быть задействованы новые модули. Фактически можно использовать режим «пакетирования», при котором даже сходные между собой однотипные (например, кредитные) продукты обслуживаются в разных модулях. В рамках такой архитектуры свободно существуют «нишевые», ориентированные на конкретный банковский продукт программные модули.

Анализ мировых тенденций показывает, что эффективная реализация сложных банковских продуктов возможна только в распределенной многомодульной архитектуре. Это дает возможность сохранить единую точку обслуживания клиентов, ради которой, собственно, и создается фронт-офис, и сохранить единый операционный блок банка, обеспечивающий, несмотря на все маркетинговые различия продуктов, строгое соблюдение национальных финансовых и налоговых правил и требований управленческого учета. Наиболее современной парадигмой такой архитектуры является Service Oriented Architecture (SOA) – технология разработки распределенных систем, функциональность которых обеспечивается с помощью сервисов (служб). Службы взаимодействуют между собой посредством сообщений и реализуют бизнес-функции и правила, описанные их контрактом.

Однако не нужно строить иллюзий по поводу легкости создания такой модульной архитектуры. Провести разделение системы с монолитной архитектурой всего лишь на 2 модуля так же сложно, как разделить сиамских близнецов. При этом некоторые модули невозможно «разорвать» в принципе, поэтому их придется полностью переписать, а ряд других – оснастить «избыточными» функциями выгрузки-загрузки данных. Ввиду этого модульная архитектура не снимает требований к комплексному тестированию системы и, более того, даже делает эту задачу сложнее. Ведь модули являются «активными» участниками системной среды, и если их работа будет происходить на нерасчетных характеристиках, типах данных и временных датах – они могут непредсказуемо влиять на бизнес-процесс в целом. Из-за этого, помимо статического тестирования, придется предусмотреть варианты динамического контроля и наблюдения за программным комплексом.

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

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

Соответствующая всем вышеперечисленным требованиям стратегия развития программных продуктов компании «Диасофт» направлена на разработку и продвижение Финансовой Архитектуры Diasoft FA# (Diasoft Financial Architecture).

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

простота развертывания и использования, низкие эксплуатационные требования и высокая производительность, присущие фронт-офисным приложениям;

высокая функциональная готовность, надежность и продуктовая направленность, характерные для бэк-офисов;

комплексный подход к консолидации и анализу первичных и учетных данных, невозможный без полноты моделей Хранилищ данных и широты охвата построенных на их основе витрин данных;

открытость и процессная ориентация, свойственные современным интеграционным платформам.

Какие же наиболее интересные модули (и соответствующие тенденции) появились на рынке автоматизации банковского розничного обслуживания в недалеком прошлом и будут развиваться уже в ближайшее время?

Центр обработки звонков (Сall Сenter)

Так специалисты предлагают по-русски называть уже знакомую в банковском мире услугу Сall Сenter. Центр обработки вызовов (ЦОВ) позволяет обслуживать большое количество клиентских обращений, придавая этому обслуживанию оттенок личного общения между клиентом и сотрудником банка. В настоящее время существует достаточное количество математических моделей расчета характеристик ЦОВ и оценки их экономической рентабельности. Так, в соответствии со сложившейся сегодня в России практикой банковский ЦОВ целесообразно организовывать в том случае, когда ежедневное количество однотипных клиентских запросов превышает 400–450, что обеспечит фронт работ не менее 10 банковским операторам.

Более точно рассчитать необходимую пропускную способность ЦОВ можно по формулам Эрланга или при помощи специальных онлайновых калькуляторов, широкий спектр которых размещен на webсайте www.erlang.com.

Немалый интерес представляет и накопленная по данному направлению статистика. Так, средняя продолжительность телефонного разговора, в рамках которой клиенту предоставляется типичная консультация по кредитной карте, составляет 4,67 минуты, а среднее время поствызовной обработки – 7,56 минуты.

Таким образом, при работе 10 банковских операторов свыше 80% клиентских звонков гарантированно обслуживаются с высоким уровнем качества. С расширением продуктового ряда программное обеспечение ЦОВ дает банку возможность перераспределять потоки обслуживания между автоинформатором, консультантом и ведущими специалистами. Банк также может использовать ЦОВ не только для прямой работы, но и для проведения промо-акций, транслируя во время ожидания ответа оператора новостную информацию, справки о банке и его партнерах и т.д.

Несмотря на то что мы присутствуем при зарождении данной отрасли, сегодня ежегодный прирост российского рынка ЦОВ составляет порядка 21%, что почти в 2 раза превышает аналогичные показатели европейского рынка. По оценке компании Datamonitor, к 2008г. в России будет создано 3880 Call-центров, а число рабочих мест операторов вырастет до 180 тыс.

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

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

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

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

Данный подход к оценке кредитоспособности заемщика существенно упрощает работу банковской службы безопасности, которой фактически остается лишь обнаруживать утерянные и недействительные паспорта, а другие представленные потенциальными заемщиками документы – справки о доходах и месте фактического проживания – будут носить вспомогательный характер. Такая тенденция находит свое отражение и в составе анкет кредитных заемщиков: доля «документальной информации», которую банк может быстро, однозначно и недорого проверить, не составляет обычно более 30% от всех вопросов анкеты.

И, наконец, третьей причиной невысокой распространенности скоринга является то обстоятельство, что как минимум из пяти наиболее популярных на рынке скоринговых методик, от простейшей – «экспертной», в рамках которой определяются балльная оценка и весовая функция от значения полей в анкете заемщика, до сложных методик с применением нейронных сетей, «деревьев решений» или регрессионного анализа, нет ни одной «идеальной». Каждая из них имеет как своих поклонников, так и критиков. Российское банковское сообщество, к сожалению, даже не имеет в своем распоряжении хоть сколько-нибудь серьезных переведенных монографий на эту тему, поскольку расцвет скорингового бизнеса пришелся на 1980–1990 годы, когда серьезные математические работы на русский язык уже не переводились. В результате подавляющая часть литературы на тему скоринга доступна сегодня только на английском языке, и возможность воспользоваться серьезными монографиями в переводном варианте у российских банковских специалистов отсутствует.

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

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

Обобщенная скоринговая модель, «generic» карта, содержит лишь обобщенные параметры заемщика, и по мере накопления клиентской статистики будет постоянно снижать точность расчетов, выдавая, соответственно, такие же «обобщенные» выводы. Снижение точности связано с тем, что внутри клиентской массы начинают формироваться группы, сегменты клиентов, разделенные по таким граничным параметрам, как возраст, место проживания, уровень дохода, занимаемая должность, и т.д. И через некоторое время такая скоринговая модель будет прогнозировать результат с точностью, едва превышающей 50%.

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

Данные скоринговые схемы обеспечивают распознавание «плохого»/«хорошего» клиента с точностью до статистически значимых математических величин – свыше 70–75% – и производят еще более точные расчеты по мере накопления статистики на каждом клиентском сегменте. Облегчить внедрение скоринговой модели позволяет переход от точности расчетов скоринговой модели к более понятному банкам языку прибыли/убытков. Показательным в данном случае можно назвать тот факт, что уже при первом тесте программное обеспечение Scorto™ «Scoring Solution», предлагаемое компанией «Диасофт», верно распознало «плохих» заемщиков в представленной одним из банков выборке из 1000 реальных анкет. При этом ожидаемая сумма убытков, которые банк мог понести из-за возможного дефолта плохих заемщиков, превысила 12 млн. рублей. После этого анализа сомнений в необходимости внедрения данного программного продукта у банка не осталось.

Сбор клиентской задолженности (Debt Collection)

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

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

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

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

просмотр задолженностей в разрезе клиента/группы клиентов/филиала банка;

просмотр задолженностей в разрезе продуктовых рядов, подвидов договоров;

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

рейтингование (возможно, с использованием «поведенческого скоринга») задолженностей и выработка стратегии управления ими (взыскания, списания, дисконтирования, цессии и т. д.);

учет контактов с клиентом и заявок на пролонгацию, перекредитование, изменение календаря платежей;

механизм для аккумулирования активов клиента и разнесения (полного или частичного) сумм задолженностей;

работа с модулями секьюритизации по автоматической балансировке кредитных портфелей (например, не более 30% кредитов с просрочкой не более 1 месяца, 50% – «хороших», ипр.) и лимитов;

работа не только с кредиторами,

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

На зарубежном финансовом рынке такой модуль обычно обозначается термином Debt Collection, однако новизна данного решения для отечественного рынка пока не позволяет присвоить ему адекватный русский термин.

Написание такого программного решения признано перспективным компанией «Диасофт», и сейчас наши разработчики работают над созданием соответствующего продукта, а в ближайшее время мы станем свидетелями его выхода на российский рынок.

Комментарии (0):

Добавлять комментарии могут только зарегистрированные Пользователи


Читайте в этом номере:
обновить

а вы знаете, что...

… предоплаченные платежные карты возникли как платежный инструмент в середине 1990-х гг., и первыми из них были карты Electronic Benefits Transfer (EBT) в США, на которые заменили ранее выдаваемые нуждающимся бумажные продовольственные сертификаты?