Объем клиентской базы определяет размер хранилищ данных для маркетинга, основанного на данных. Второе важное измерение – степень сложности требований. На рис. 10.3 приведена методика, позволяющая понять, какая инфраструктура хранилища данных нужна (с учетом этих измерений). Как я уже говорил в предыдущем разделе, сложность требований к данным определяется тем, какие вопросы вы хотите задать и какие ответы получить.

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

_{Рис. 10.3. Сложность требований}

_{Рис. 10.4. Связи между данными для ретейла с низким уровнем сложности}

^{Источник: Ричард Уинтер, www.wintercorp.com}

Что это за оборудование? Оно помогает создать недорогую информационную систему, способную выполнять одну-единственную функцию (подобно микроволновой печи на вашей кухне, которая только разогревает еду). Витрина данных для маркетинга требует сравнительно простой модели, наподобие приведенной на рис. 10.4; при этом она способна обрабатывать большие массивы данных. Этот пример с небольшой сложностью и большим объемом данных соответствует верхнему левому квадранту на рис. 10.3. В данном случае вместо домика для фермера вы строите большую, но простую структуру. Например, огромную парковку, для повышения емкости которой нужно добавить дополнительные места.

Сложность требований возрастает, когда компании для принятия решений нужны данные из различных источников, а их обработка носит нелинейный характер. На рис. 10.5 приведен пример модели расчета данных для CLTV в области ретейла. В данном случае имеется и масса сложностей с точки зрения аналитики, и различные, не связанные между собой наборы фактов, и сложная паутина взаимосвязей (что вполне нормально для сложных моделей).

_{Рис. 10.5. Сложные взаимосвязи, учитывающие пожизненную ценность клиента}

^{Источник: Ричард Уинтер, www.wintercorp.com}

С точки зрения масштабов инфраструктуры сложность требований может оказаться значительно более важной, чем количество клиентов. Нижний правый квадрант на рис. 10.3 соответствует сравнительно небольшому количеству клиентов, однако работа в нем связана с серьезными сложностями. В качестве примера приведу известную мне крупную производственную компанию из списка Fortune 500 с миллионом B2B-клиентов. Объем данных, связанных с этими клиентами, составлял всего 1 терабайт, то есть в случае низкой сложности требований инфраструктура могла бы представлять собой «фермерский дом».

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

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

В этом примере миллион клиентов создавал 1 терабайт прямых данных, а сложные и разносторонние отношения с ними – еще 10 терабайт производных. Иными словами, вследствие сложности отношений реальный объем данных составил 11 терабайт. Откуда же возникла эта сложность? Свою лепту внесли и перемещения внутри 1 миллиона корпоративных клиентов, и 10 тысяч продавцов, и более 100 тысяч записей, связанных с различными взаимодействиями, и более 10 тысяч продуктов, и т. д. Если вы спросите: «На какой объем продаж продукта Y в регионе X мы можем рассчитывать в этом квартале?» (вопросы, связанные с территорией, продуктом или клиентами, обычно считаются простыми) – то для этой компании ответ будет крайне сложным из-за большого количества перемещений клиентов.

Кроме того, сложность возрастает примерно в 10 раз, если компании требуется получать данные в режиме реального времени – например, проводить анализ CLTV «на лету» и использовать его в работе колл-центра, как в Королевском банке Канады (см. рис. 6.5). Верхний правый квадрант на рис. 10.3 представляет собой Эмпайр-стейт-билдинг в области инфраструктуры: большое количество клиентов и сложные требования. Такая инфраструктура для маркетинга, основанного на данных, обойдется в 50–250 миллионов долларов.

Возможно, вы уже запутались в битах, байтах, передаче данных, скоростях и многомиллионных инвестициях. Но именно они ключ к победе. Нужно заранее продумать модель работы с данными – точнее, необходима масштабная картина, основанная на том, какие ответы вы хотите получить. Именно требования бизнеса покажут вам, какого рода инфраструктуру следует создавать: фермерский домик или Эмпайр-стейт-билдинг. Однако не стоит строить небоскреб с нуля. Большинство известных мне успешных компаний начинали с малого: они понимали, как должна выглядеть итоговая модель, но создавали ее постепенно, одну таблицу за другой, применяя принцип 80/20 (сначала обрабатывали 20 % данных, которым соответствует 80 % ценности). Поэтому первый цикл модели может быть достаточно простым (наподобие приведенного на рис. 10.3). Достигнув успеха в малом, вы сможете вносить новые данные и усложнять модель (см. рис. 10.4).

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

В 1995 году Continental Airlines имела 45 различных баз данных. Их объединение в централизованное хранилище позволило экономить по 5 миллионов долларов в год. Экономия была обусловлена рядом факторов: меньшее количество контрактов с поставщиками баз данных, сокращение времени на переговоры с ними, меньшая площадь для оборудования (а соответственно, сокращение накладных расходов). Однако, что важнее всего, для обслуживания этого «монстра» требовалось меньше администраторов. Объединение различных баз данных в единое хранилище называется консолидацией витрин данных; понятно, за счет чего складывается экономия в рамках этого процесса{53}. Однако здесь возникает дилемма: переносить данные в текущем формате или изменять их архитектуру для новой системы?

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