`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

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

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Александр Кучерук

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

+33
голоса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+33
голоса

Напечатать Отправить другу

Читайте также

1) Как мне кажется упущен один важный момент -- для КАКОГО банка? Не бывает одинаковых рецептов для всех пациентов.

2)Не слышал чтобы в банках как-то были часто используемые аналитические модели Oracle или SAP, по-моему это не сильная сторона этих вендоров. А вот Sybase, IBM, SPSS -- это да. И Teradata -- тоже да. И есть также несколько неизвестных широкому кругу компаний, специализирующихся на аналитических моделях для банков.

1)Одинаковых рецептов несомненно нет, а вот строение "организма пациента" практически всегда одно и тоже:
Клиенты, Сделки, Платежи, Продукты, Портфели, Кампании, Баланс и т.д. И все надо анализировать.
И болячки не сильно отличаются:
Слабая клиентская база, ухудшение состояния кредитного портфеля, низкий и затратный возврат просроченных долгов, слабая и неконтролируемая эффективность маркетинговых кампаний. низкая доходность на клиента, трудно прогнозируемая ликвидная позиция и др.
Только у кого то одна болячка и острая, а у другого несколько вялотекущих. Все зависит от рыночной позиции банка.
И "рецепты" конечно должны соответствовать задачам.
Да собственно хотел написать не столько про модели, сколько про подход к решению задач, который требует КАКОЙ ТО модели.
Согласен, что проблема дискуссионная. Приглашаю к обсуждению.
2) индустриальные модели покупаются банками. Я такие примеры знаю. И мы их внедряли.

Не помню откуда скопипастил...
"Если потребность имеет стратегический характер, то вне зависимости от других факторов необходимо создавать продукт
самостоятельно. В противном случае вам придется играть по правилам ваших конкурентов вместо того, чтобы создать
продукт, полностью удовлетворяющий вашим текущим и будущим потребностям." (c)

Отсюда: http://www.ibm.com/developerworks/ru/library/j-eaed10/index.html

Кстати, в продолжение поста автора очень рекомендую 3 статьи из серии.

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT