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

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

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

Самыми трудоемкими (не сложными методологически или технологически, а именно трудоемкими) являются задачи:

– вообще найти требуемые данные. Данных в системах много, все нужны для учета, но какие нужны для хранилища? Все?

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

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

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

– иметь возможность выгружать данные за приемлемое время, как исторические, так и ежедневные порции обновляемых данных. Если данные в АБС или карточной системе сформированы к 02:00, а рабочий день начинается в 09:00, хватит ли 7 часов для выгрузки данных из источников и загрузить в ХД? А если позже данные в АБС будут формироваться к 05:00, успеет ли система подготовить отчеты к началу рабочего дня?

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

И по трудоемкости эти задачи могут занимать до 70% трудоемкости проекта.

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

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

– неэффективные коммуникации в проекте, вызванные разным уровнем подготовленности участников к проектной работе и ведению проектной документации,

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

– ограниченные ресурсные и методологические возможности заказчика при проверке аналитических показателей в многомерной модели «плоскими» бухгалтерскими способами и недокументированными SQL запросами.

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

– презумпция виновности исполнителя:

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

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

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

– неожиданные глюки в самой платформе

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

Может у кого то есть и другие впечатления от подобных проектов, которые в той или иной степени внедряются во многих банках?

Буду рад возможности обсудить как риски, так и мероприятия по их демпфированию/устранению.

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

А как эта ценность ощущается менеджментом?

Судя по статьям расходов, проекты внедрения аналитических приложений часто являются затратами на ИТ-системы. Со всеми вытекающими отсюда последствиями как для проектов, так и для их результатов.

Главным достижением считается наименьший бюджет, а лучше вообще собственными силами сделать.

При этом мнение будущих пользователей не является определяющим.

Почему же внедрение аналитики считается затратой, а не инвестицией?

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

Может аналитикой называют то, что не показывает возможности создания добавленной стоимости?

Может быть потому, что пользователям трудно интерпретировать результаты аналитики так, чтобы руководители увидели реальную ее ценность для бизнеса?

Вероятно все это и так и не так.

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

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

Не показали, потому что это либо сложно, либо рискованно, либо непонятно, либо лично не интересно.

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

Как вариант ответа на вопрос как разорвать такой круг, надо просто познакомиться с результатами решения одной-двух наиболее актуальных бизнес-задач средствами аналитики. И это не фантастика из западных best practice. Многие банки уже пошли по этому пути. Некоторые достигли определенных результатов. Для операторов мобильной связи это обязательная часть приложений.

Например, можно показать как качественное прогнозирование вероятности перекрестных продаж показывает возможность для уменьшения затрат на проведение маркетинговых обзвонов в 2,5-3 раза.

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

А это уже вполне измеримые экономические показатели.

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

Но без желания и воли руководителей такой процесс даже не начинается.

Опять замкнутый круг?

Есть ли в проектах внедрения BI-приложений что то специфическое?

Если взять перечень рисков из PM Book, то в проектах вряд ли удастся найти нечто специфическое, некатегоризируемое ранее. Но на основании личного опыта могу все же добавить несколько категорий.

Неконтролируемое Заказчиком расширение объема требований всех подряд подразделений, сразу после осознания того, что какое то подразделение выбило деньги на аналитику и контракт подписан.

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

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

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

Недостаточная готовность аналитиков мыслить «многомерно», отнимает в начале проекта много времени на согласование моделей. А недостаточная готовность со стороны ИТ-специалистов – приводит к дополнительным временным затратам на проверку результатов загрузки данных в Хранилище (Витрину) данных, которую в конце концов приходится делать в дополнительное время, плюнув на условия контракта, где за наличие данных отвечает Заказчик.

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

Правда, если все это удается и хватает сил преодолеть, то Заказчик начинает доверять вам и предлагаемому вами решению.

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

Именно потраченных... редко когда слышал слово «инвестиция» по отношению к ИТ проектам вообще и по отношению к аналитике в частности.

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

• прогнозирование ликвидности
• автоматизация маркетинга
• клиентская сегментация
• оценка взыскания просроченной задолженности
• и др.

И в ходе анализа стоящих задач почти всегда приходится сделать и анализ ROI для таких проектов, НО:

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

2. Когда же цифры не вызывают сомнения и концептуально принимаются, то встает другой аргумент: «ну получим мы эти данные в 10 раз быстрее и в 10 раз точнее с затратами в 10 раз меньшими, а что нам дальше делать? Где найти таких аналитиков/исполнителей/менеджеров/... которые смогли бы воспользоваться этими преимуществами и осуществить прорыв в нашем бизнесе с помощью полученных новых знаний?

3. Когда же и потенциальная достижимость результатов не вызывает сомнения, и молодой, задорный, активный персонал имеется, у потенциального заказчика возникает вопрос: «а где нам найти ресурсы для того чтобы реализовать те возможности, которые дает это новой знание?» Видимо опасаясь, что руководство так просто в расчеты не поверит и заставит принять личную ответственность за потраченные деньги. А кому оно надо?

И начинаешь задумываться, а нужна ли аналитика? Нужны ли новые знания? Нужны ли новые возможности?

Или может быть нужны другие способы предварительной оценки эффективности?

Или нужны другие, не только финансовые расчеты и доводы?

Мне доводится довольно часто просматривать маркетинговые материалы на сайтах крупных интеграторов, посвященные теме «Бизнес – аналитика»/Business Intelligence/BI. Наверняка эта информация адресована потенциальным потребителям этих продуктов и услуг.

Читаю выборочно

…«адаптация моделей банковских данных…»

«…инструменты BI платформ…»

«…Data Marts, Data Mining, ETL, …»

«…динамические механизмы визуализации в портальной среде…»

и т.п.

Кто же потенциальный покупатель этих features?

Судя по используемой терминологии, вроде как потенциальным потребителем должна быть ИТ-служба.

Но зачем ИТ-службе инструменты углубленного анализа банковских данных?

Им подавай Хранилище, BI инструменты (OLAP)…

А кто заплатит за покупку Хранилища? Зачем оно например банку?

«Слышится» ответ ИТ-службы: «Чтобы все было в одном месте!!!»

На вопрос «А что собственно все?» звучит не менее твердый ответ «а все, что у нас есть в учетных системах».

И только на вопрос «А что у Вас есть полезного в учетных системах?» звучит, но уже не очень уверенно «бизнес-аналитики знают».

То есть аналитика нужна бизнесу? И все перечисленные выше возможности тоже нужны бизнесу?

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

Им надо решить простую и понятную им задачу, например осуществить прогнозирование суммы резервов на покрытие дефицита ликвидности с учетом всех факторов, действующих на ликвидность. Или решить задачу прогнозирования доходности клиента. Или другую подобную аналитическую(!) задачу. Могут ли они найти ответ на свои вопросы из упомянутых выше маркетинговых материалов? Ответ почти очевиден.

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

«Нет… это задача бизнес-подразделений описать подробно аналитические задачи! А мы их тут же все и порешаем!» твердят ИТ-специалисты.

«Так мы же Вам уже сто раз это все писали, а вы говорите, что сделать так нельзя…»: отвечают бизнес-аналитики.

В итоге бизнес-подразделения, слушая все эти споры, молча и упорно решают свои задачи при помощи верного Excel и своего времени после работы и в выходные.

А потом по нескольку раз переделывают, опять за счет рабочего и нерабочего времени. Наверное время у нас ничего не стоит…

* А там, где стоимость времени специалиста по решению бизнес-задачи известна (в том числе и благодаря аналитическому приложению, к примеру АВС), ему не разрешат тратить столько дорогого времени на «рукопашную борьбу» в Excel.

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

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

Мне кажется что пока что у нас аналитику покупают как последнюю надежду, когда уже никакие модернизации АБС, или CRM, или Call Center не приводят к существенному улучшению контролируемости бизнеса.

Покупают в спешке, без подготовки, с завышенными надеждами на чудодейственную силу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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