Аналитическая модель для банка: Разрабатывать самим или купить готовую?

14 октябрь, 2011 - 18:12Александр Кучерук

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

Для ответа на этот вопрос взял личный опыт участия в проектах разработки аналитических CRM-приложений.

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

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

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

Эта информация обычно храниться в разнообразных учетных системах, часто повторяющаяся, иногда противоречивая.

Вопросы о том:

  • какую информацию надо собирать для целей дальнейшего анализа клиентов и их поведения?
  • какая детализация информации необходима?
  • какие преобразования (агрегация, консолидация) исходных данных потребуются?
  • как организовать процесс согласования среди различных бизнес-подразделений?
  • как контролировать корректность извлекаемых данных?
  • какие объемы данных необходимо будет обрабатывать и с какой производительностью?

волнуют большинство ИТ директоров.

Вопросы о том:

  • где найти необходимые данные о Клиентах?
  • как их организовать в виде удобном для анализа?
  • как найти общий язык с ИТ службой в вопросах формализации требований к данным?
  • как сформулировать требования к аналитике для передачи ИТ специалистам?
  • как формализовать/стандартизовать требования к аналитике?
  • как ускорить получение требуемой аналитической информации?
  • как повысить эффективность CRM приложений?
  • как из клиентских данных извлечь ценную информацию?
  • как оценить доходность Клиентов, Продуктов, Услуг, Каналов продаж?

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

Для целей согласования моделей анализа, требуемых бизнесу и моделей данных, заложенных в учетных и фронт-енд приложениях, необходима некая модель. Такая модель должна покрывать все требуемые области анализа банковской деятельности: клиенты, риски, финансы, операции. Модель должна содержать данные о требуемых объектах и разрезах анализа, метриках, предоставлять необходимый уровень детализации хранимых данных.

Такие модели предлагаются большинством производителей банковских аналитических приложений. Oracle, SAP, SAS, IBM, Sybase – каждая компания предлагает на рынке некую универсальную модель анализа Банка, реализованную в соответствующих структурах баз данных. Возможности этих моделей поражают воображение. Кажется, что не существует задачи, которую нельзя было бы решить, используя такие модели. И, по сути, это правда. Глубина проработки моделей отражает огромный многолетний опыт западных разработчиков и внедренцев. Этот опыт, помноженный на большое количество инсталляций Хранилищ, построенных на их основе, в западных (и восточных) банках в странах с развитой экономикой, и должны дать потенциальному пользователю уверенность в том, что модели, заложенные в таких системах, стоят своих денег.

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

  • Индустриальная модель анализа описана обычно на английском языке, что не всегда удобно для бизнес-аналитика, у которого кроме необходимости понять суть экономического смысла, заложенного в ту или иную сущность, появляется и необходимость понять, а правильно ли он перевел значение терминов, некоторые из которых не имеют однозначного перевода на русский/украинский языки.
  • Описание объектов, атрибутов, связей модели анализа большей частью отвечает на вопрос: «как ЭТО МОЖНО интерпретировать?», не давая четкого ответа на вопрос: «как ЭТО НУЖНО интерпретировать?», оставляя ИТ специалистам и бизнес-аналитикам широкие возможности для самостоятельного нахождения нужного ответа ПРИМЕНИТЕЛЬНО к конкретному банку. Помочь в данном случае может консультант производителя и/или интегратора, который, исходя из своего практического опыта, предложит варианты интерпретации. Данные варианты необходимо обсудить среди бизнес-подразделений и, часто, описать формально и утвердить методологически, чтобы иметь возможность пользоваться в Банке. Часто процесс внутреннего согласования занимает месяцы.
  • В ходе такого изучения и согласования обычно выявляются:
    • Что Возврат на инвестиции, сделанные в полнофункциональную индустриальную модель, весьма значительные в каждом случае, полностью окупаются в случае использования модели целиком, что в случаях использования индустриальных моделей встречается редко.
    • Что Ни достаточного ресурса, ни достаточного времени на проработку такого проекта самостоятельно Банк обычно не имеет, а вопросы согласования модели требуют такой модели, которая, прежде всего, всеми интерпретируется ОДНОЗНАЧНО.
    • Как результат наступает понимание того факта, что ЛЮБУЮ индустриальную брендовую модель необходимо СУЩЕСТВЕННО кастомизировать для достижения результата, требуемого бизнесу и, который может поддержать ИТ, и, что трудозатраты на эту кастомизацию могут быть сопоставимы с проектом разработки собственного решения.

В случае же самостоятельной разработки модели извлечения данных необходимо учесть, что трудозатраты на разработку могут составлять от 80 до 200 чел*дней. А время на разработку составляет – 3-5 месяцев и требует привлечения 2-3 специалистов по системному анализу и архитектуре. Согласование с бизнес-подразделениями также требует дополнительных 1-2 месяца. С учетом того, что срок жизни такой модели обычно год – полтора, после чего бизнес-пользователи захотят ее модификации в соответствии с изменившимися правилами ведения бизнеса, процесс обновления модели – это тоже перманентный ресурсо– и времязатратный проект, целью которого является постановка задачи на выгрузку данных из первичных источников и определение правил их обработки для последующего анализа.

Дилемма???!!!