Табл. 10.1. Инфраструктура хранилища данных – домик фермера против Эмпайр-стейт-билдинг
Источник: Ричард Уинтер, www.wintercorp.com, и Марк Джеффри, www.agileinsights.com
Ретейлер среднего размера соответствует в нашей системе офисному зданию площадью около 2440 м² (примерно в 12 раз больше фермерского домика). У него региональная сеть из 400 магазинов и 1 миллион клиентов. Объем данных для него составляет примерно 10 терабайт. Иными словами, у ретейлера среднего размера в 10 раз больше данных, чем у небольшого! Для таких объемов данных вам понадобятся и значительные мощности, и инфраструктура – это может обойтись в сумму 500 тысяч – 2,5 миллиона долларов, в зависимости от сложности анализа данных (опять же, примерно).
На третьем уровне располагается национальный ретейлер с 5000 магазинов и 100 миллионами клиентов. Здесь вполне уместна аналогия с Эмпайр-стейт-билдинг – зданием площадью свыше 200 000 м². Такое здание примерно в 1000 раз больше фермерского дома. В распоряжении национального ретейлера будут массивы данных объемом 1000 терабайт, то есть в 1000 раз больше, чем у местного ретейлера! Для работы со столь массивными объемами данных и запросов вам нужна настоящая инфраструктура промышленного масштаба стоимостью 50–250 миллионов долларов.
Вывод очевиден: разница в требованиях к системе, определяемая разницей в решаемых бизнес-задачах, может приводить к значительным последствиям; дом фермера ничуть не похож на Эмпайр-стейт-билдинг, а инфраструктура стоимостью в несколько сотен тысяч долларов – не то же самое, что инфраструктура стоимостью несколько сотен миллионов. Ричард Уинтер, СЕО WinterCorp и эксперт в области дизайна и архитектуры масштабных хранилищ данных, рассказал мне следующее:
Бизнесмены должны понимать масштаб и сложность хранилищ данных, создаваемых для них (примерно как в случае финансирования строительства здания). Они должны представлять себе, предполагает ли проект строительство дома для престарелых или башни Сирс[49] – соответственно, дизайн, техническое проектирование и конструкция будут разными. К сожалению, хранилища данных физически не ощутимы, и руководители порой затевают проекты, напоминающие по сложности и масштабу башню Сирс, при этом представляя себе, что строят обычный дом престарелых… Тут-то и возникают проблемы.
Самая сложная ситуация возникает в том случае, если ваша команда IT-отдела раньше строила только фермерские дома. Старая поговорка гласит, что, когда у вас есть только молоток, все вокруг напоминает гвоздь. Это справедливо и в отношении IТ: если вы умеете строить только деревенские дома, то ваша IT-система, обслуживающая маркетинг, тоже будет напоминать такой дом. И здесь возникает проблема масштабируемости: сможет ли система работать после добавления в нее новых клиентов? Если система хорошо работает с несколькими клиентами, будет ли она так же эффективно работать с сотнями?
Ошибка, связанная с невозможностью масштабирования, возникает очень часто, а ее последствия получают широкую огласку. В 2001 году AT&T[50] начала брендинговую кампанию для mLife, пакета услуг мобильной связи. Кампания, запущенная в период проведения Суперкубка по американскому футболу в 2001 году, обошлась фирме более чем в 20 миллионов долларов. Телевизионные ролики были очень простыми: адрес сайта www.mLife.com на белом фоне. Однако в итоге более 100 миллионов зрителей Суперкубка ожидало разочарование: когда на сайт зашло одновременно огромное количество пользователей, он рухнул, и никто не смог понять ни что такое mLife, ни каким образом сайт связан с AT&T. Так погиб только что родившийся бренд. Это классический пример того, что происходит, когда сотрудники отдела маркетинга не общаются с IT-специалистами.
Приведу еще один пример. Специализированная сеть продуктовых магазинов, включавшая несколько сотен магазинов с годовым доходом более 10 миллиардов долларов, решила внедрить новую систему для снижения числа ситуаций нехватки товара на складе. Ретейлер, торговавший свежими натуральными продуктами, знал из результатов исследования рынка, что снижение дефицита на складах помогает значительно повысить и прибыльность, и уровень удовлетворенности клиентов. Идея состояла в том, чтобы анализировать данные о запасах в каждом магазине и вычислять, какие продукты необходимо довозить каждый день (свежие фрукты, йогурт, рыбу, говядину и т. п.). Магазины начинали работу каждый день в 9 утра, а с полуночи до 5 утра грузовики загружались на центральном складе, чтобы товары попали в магазины уже к 6 часам.
Создав EDW, IT-команда поняла, что возможностей используемой системы хватает только на обработку данных по одному магазину (причем процесс будет длиться всю ночь). Однако компании нужно было решение, способное просчитать данные по сотням магазинов за три часа (с 9 вечера до полуночи). Управленческая команда неправильно поняла требования. Система была логически верной, однако не могла выполнять свою функцию: никто не подумал о том, чтобы просчитать объем мощности, необходимый для управления значительными массивами данных. Как рассказал мне Уинтер:
Проблемы с масштабируемостью хранилищ данных возникают в самый неподходящий момент. Они могут появиться на этапе проектирования или создания технических решений – часто из-за того, что требования к системе слишком расплывчаты или платформа выбрана неверно. Однако вы не узнаете о проблеме до момента полной загрузки системы. Проблемы с масштабируемостью, которые выявляются на ранних этапах, легко исправить, однако проблемы, возникающие на поздних этапах, способны уничтожить проекты, карьеры и целые фирмы.
Вы как руководитель маркетинговой команды можете испытывать серьезные проблемы при работе с IT, так как, скорее всего, это не ваша область. В каком-то смысле владельцы бизнеса, где применяется маркетинг, основанный на данных, напоминают владельцев футбольных клубов. Владельцы не тренируют футболистов. Они только оплачивают счета, но при этом им нужны результаты, чтобы продавать билеты на стадионы.
Как же маркетеру решить эту задачу? Предлагаю обратиться к теме, которая хорошо знакома специалистам по маркетингу. Что если кто-то из сотрудников вашей компании представляет вам нереальный план продаж? Скорее всего, вы начнете задавать вопросы, позволяющие понять, каким образом он хочет достичь желаемой цели: каковы прогнозы, что говорят данные исследований рынка, какие меры предпринимаются для реализации плана и т. п.
То же справедливо для инфраструктуры маркетинга, основанного на данных.
Если вам сложно найти общий язык с IT-командой, попросите ее представить вам собственный план создания программы для обработки большого массива данных. В приведенном выше примере (дефицит на складе ретейлера) маркетер должен задать команде вопрос: «Способны ли вы собрать данные со всех 500 торговых площадок, импортировать их в EDW и проанализировать к полуночи, с тем чтобы мы могли загрузить грузовики продуктами к 5 утра?». Пусть она предоставит инженерные выкладки, показывающие, что это возможно. Можно также попросить независимых экспертов оценить представленный план.
Вам, как и владельцу футбольного клуба, необходимо знать, что ворота установлены в правильном месте на поле, что команда решает грамотно поставленную задачу и у нее есть разумный план по перемещению мяча в нужном направлении и зарабатыванию очков. Следовательно, вы должны принимать во внимание масштаб решаемых проблем, а это даст возможность понять, нужна ли вам инфраструктура размером с домик для фермера или Эмпайр-стейт-билдинг. Как я уже говорил, технологии для маркетинга, основанного на данных, – слишком важный вопрос, чтобы оставлять его на откуп IT-отделу.
