Сложность требований возрастает, когда компании для принятия решений нужны данные из различных источников, а их обработка носит нелинейный характер. На рис. 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 независимых баз данных. Это приведет к снижению расходов на обслуживание системы, но сами данные никак не изменятся. Однако в этом случае вы, как и раньше, не сможете дать ответы на важные вопросы, стоящие перед компанией.
Почему это важно? Многие руководители маркетинговых подразделений в разговорах со мной жаловались, что новое хранилище данных в их компании не дает им возможности получить ответы на самые простые маркетинговые вопросы. В чем же была проблема? Отдел IT увлекся идеей экономии расходов за счет консолидации данных в одном крупном хранилище, но не обратил внимания на суть проблем бизнеса: чтобы получить целостную картину, необходимо было изменить архитектуру данных.
Новая архитектура предполагает необходимость продумать все сложные взаимосвязи и оптимизировать модель данных так, чтобы она могла отвечать на самые важные для маркетинга вопросы. Разумеется, изменение архитектуры приводит к росту расходов, однако это с лихвой компенсируется новыми преимуществами. Однажды я рассчитал финансовые последствия двух вариантов работы (простой миграции данных или изменения архитектуры) для крупного финансового учреждения{54}. Оказалось, что решение, основанное на новой архитектуре, позволяет повысить NPV в три раза!
