Особенность ритейла – большой объем данных, так, в «Рив Гош» – сотни тысяч карт лояльности, в «ЛИКАРДе» – около 20 млн карт лояльности и несколько миллионов операций в день. Это обстоятельство сразу определяет некоторые особенности технического решения. Под такие объемы обязательно нужен отдельный сервер БД для хранения витрины данных, так как использование таблиц транзакционных систем или хранение витрины в отдельной схеме на сервере БД транзакционной системы приведет к большим проблемам производительности отчетов. Также такой объем данных сразу указывает на то, что в БД, где хранится витрина данных, необходимо использовать опцию секционирования таблиц и по возможности строить запросы в пределах одной секции или рассчитывать агрегаты – месячные, квартальные и т.д.
Что дает BI
Наша практика показывает, что основными направлениями использования BI-систем в ритейле являются:
Сегментация клиентской базы – построение при помощи BI-решения списков, которые затем обрабатываются в CRM-системе для запуска маркетинговых кампаний, рассылки SMS и т.д. Мы настраивали подобную интеграцию Siebel CRM и Oracle BI в «Рив Гош» и текущем банковском проекте. Аналитика производится в системе BI, где можно отобрать данные как по широкому набору параметров клиента (пол, возраст, место жительства), так и по его операциям, например, сумме покупок за предыдущий месяц. Результаты этой аналитики сразу попадают в CRM-систему для дальнейшей обработки.
Анализ успешности проведенных маркетинговых кампаний – построение отчетов, показывающих эффективность кампаний и акций. Сейчас мы строим витрину данных и отчеты по маркетинговым кампаниям в банковском проекте. Стоит сказать, что построение системы отчетности в этой предметной области осложняется развитой системой связей между сущностями в CRM – часто они соединены по схеме «многие-ко-многим». Поэтому при проектировании предметной области необходимо тщательно продумывать схему соединения таблиц, чтобы избежать «кольцевых» связей, и далее при разработке отчетных форм аккуратно настраивать фильтры отчетов.
Анализ эффективности работы персонала – в данном случае оценка эффективности call-центра заказчика осуществляется средствами BI.
Бизнес-отчетность (сумма продаж, прибыль, лояльность и т.д.): часто построение такой отчетности требует интеграции BI-решения не только с CRM-системой, но и с финансовой транзакционной системой или с хранилищем данных. Эта отчетность – самая обширная и сложная по построению, так как бизнес-отчетность у каждого заказчика своя, и невозможно предложить готовое «коробочное» решение, которое удовлетворило бы всех. В наших проектах мы внедряем разные решения: в банковском проекте единственным источником данных служит CRM-система, в «Рив Гош» для построения отчетности потребовалась интеграция с существующим чековым хранилищем, а в «ЛИКАРДе» мы внедряем полноценное хранилище данных.
Ad - hoc запросы: в этих случаях мы проводим обучение сотрудников заказчика работе с инструментарием построения запросов BI-системы, чтобы продвинутые пользователи могли не только запускать предварительно разработанные отчеты, но и строить их самостоятельно под нужные критерии.
Подводные камни BI-проектов
По нашему опыту, построить универсальную предметную область BI для реализации всех перечисленных пунктов невозможно, так как цели получаемых отчетов и используемые для построения отчетности сущности различны. Обычно изначально заказчик заинтересован одним проектом одновременно «закрыть» все или почти все пункты, но тогда этот проект растянется на годы и станет слишком ресурсоемким. К тому же администрировать его будет крайне сложно и для нас, и для заказчика. Поэтому при внедрении системы бизнес-анализа в ритейле мы всегда предлагаем компании разбивать все работы по проекту на более мелкие этапы, чтобы можно было получить первые результаты за обозримое время. Как правило, один этап включает работы по реализации одной предметной области.
Стоит также сказать несколько слов о том, какие подводные камни могут подстерегать при внедрении BI и после него. Одна из часто встречающихся ошибок заказчиков – нежелание отказываться от старых привычек при анализе данных, в частности, от использования MS Excel. Бывает, что заказчик пытается сформировать в BI отчет на несколько миллионов записей и затем экспортировать его в Excel для дальнейшей обработки – сортировки, группировки, фильтрации и т.д., хотя все эти операции могут быть сделаны внутри BI. Этот путь тупиковый: BI не предназначен для таких операций и в любом случае не будет делать это хорошо. Решение одно – вся аналитика должна быть сделана внутри BI, а работа с большими списками должна осуществляться через модуль сегментации или BI Publisher.
Другая часто встречающаяся ситуация: клиент заказывает предметную область под Ad-hoc запросы, планируя разрабатывать отчеты самостоятельно. При этом наших аналитиков не подключают к анализу предполагаемых отчетов, соответственно, при проектировании и разработке предметной области невозможно правильно заложить таблицы – агрегаты: в результате запросы идут к детальным данным, а из-за их большого объема наблюдается низкая производительность отчетов. Решение – заказывать не просто предметную область BI, но и разработку некоторого количества характерных отчетов, чтобы мы как исполнитель могли проанализировать их, правильно спроектировать агрегаты при построении витрины данных, а к детальному слою обращаться только для детализации результатов.