Литмир - Электронная Библиотека
A
A

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

Новая архитектура предполагает необходимость продумать все сложные взаимосвязи и оптимизировать модель данных так, чтобы она могла отвечать на самые важные для маркетинга вопросы. Разумеется, изменение архитектуры приводит к росту расходов, однако это с лихвой компенсируется новыми преимуществами. Однажды я рассчитал финансовые последствия двух вариантов работы (простой миграции данных или изменения архитектуры) для крупного финансового учреждения{54}. Оказалось, что решение, основанное на новой архитектуре, позволяет повысить NPV в три раза!

Что может пойти и пойдет не так (если вы не будете осторожны)

На обочине бизнеса покоятся останки масштабных IT-проектов, потерпевших крах (и проекты хранилищ данных не исключение). По оценкам Standish Group, ежегодно отслеживающей состояние тысяч IT-проектов, не менее 72 % проектов не завершаются в срок или в рамках оговоренного бюджета. Иными словами, вероятность того, что система с самого начала будет работать, как задумано, составляет всего 28 %. Что касается EDW, то здесь ситуация выглядит еще менее радужной: Барбара Уиксом и Хью Уотсон{55} обнаружили, что, по словам 55 % руководителей, новая система хранения данных не может обеспечить необходимые результаты.

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

• Отсутствие сосредоточенности и ви́дения – общие цели усилий по развитию EDW недостаточно хорошо определены.

• Отсутствие поддержки (в том числе финансовой) со стороны высшего руководства.

• Отсутствие «борца», способного продвигать проект и обеспечивать информацию, материальные ресурсы и политическую поддержку.

• Организационная политика и культурные вопросы.

• Недостаточность ресурсов – финансов, времени и/или персонала.

• Масштабируемость решения – компании строили «дом для фермера», хотя нуждались в Эмпайр-стейт-билдинг.

• Технологии – система может быть основана на новой и незнакомой технологии, либо изначально выбрано неправильное технологическое решение.

• Отсутствие навыков – команде, занимающейся внедрением, недостает навыков и знаний для работы с системой. Для удачного запуска масштабных проектов в области EDW нужны отличный менеджер проекта и опытная команда технологов.

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

• Расчет на внешние ресурсы – зачастую работа перекладывается на плечи внешних подрядчиков, а IT-команда принимает результаты. На самом деле маркетерам может быть нужно что-то отличное от того, что предлагает подрядчик. В ряде случаев внутренней IT-команде не удается поддерживать предложенную подрядчиком систему в рабочем состоянии.

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

• Неучастие конечных пользователей – эта проблема может быть связана с плохим знанием их потребностей. Если отдел маркетинга не вовлечен в работу, то IT-проект по созданию хранилища для маркетинга, основанного на данных, оказывается мертворожденным.

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

Проверьте свой проект по всем этим пунктам. Все эти риски серьезны, но наиболее опасны отсутствие ви́дения и поддержки руководства, политические игры, отсутствие ресурсов, неспособность к масштабированию и низкое качество базы данных. Проблема отсутствия ви́дения удивительна, но возникает очень часто. Я встречал руководителей компаний из списка Fortune 500, которые тратили более 30 миллионов долларов на создание EDW, но при этом не задумывались над тем, что будут делать с данными, когда те окажутся в их распоряжении. Вот почему так важно начинать с небольших проектов и обучаться в процессе их реализации. Перед тем как приступать к строительству «небоскреба», нужно четко сформулировать стратегию маркетинга, основанного на данных.

Качество данных – особенно сложный вопрос. Если вы работаете в крупной организации, то, скорее всего, данные хранятся во множестве баз и в различных форматах. Для каждого клиента у вас есть различные записи, данные и описания. Кроме того, одни и те же вещи могут называться по-разному. В целом работа по очистке данных, извлечению нужных и их загрузке в EDW может оказаться сложной и затратной. Например, одна компания проанализировала свои 70 систем, в которых хранились данные о потребителях. Оказалось, что для 20 миллионов клиентов у нее было 200 миллионов уникальных идентификационных кодов!

Маркетеры авиакомпании Continental Airlines решили рассылать особо ценным клиентам благодарственные письма на день рождения и указывать количество лет, проведенных с компанией. Очистка данных для этой кампании оказалась нетривиальной задачей: помимо того что форматы дат в Европе и США различаются, оказалось, что данные о новых клиентах отслеживались лишь с конца 90-х.

Разумеется, я не хочу вас пугать. Моя задача в том, чтобы вы приступили к созданию масштабной инфраструктуры для маркетинга, основанного на данных, понимая суть вопроса. У вас не получится решить проблему сразу. Если рассматривать вопрос очистки данных, то даже если у вас имеется 150 предметных областей, вы можете выделить некоторые из них и понять, что вы хотите с ними делать. Можно гарантировать возникновение проблем с дублированием данных, их отсутствием, неправильным форматом или единицами измерения и т. д. Прежде всего выявите суть проблемы, а потом сосредоточьтесь на интеграции нескольких информационных источников – например, объедините три вида данных в течение первых шести месяцев. Главное – постепенно обеспечивать нарастающую ценность и четко следовать плану движения к цели.

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

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

В главе 2 я рассказал о пяти барьерах на пути к маркетингу, основанному на данных, стратегиях преодоления политических разногласий и получении поддержки руководства. Цель в том, чтобы одержать быструю победу, показать убедительные результаты и использовать их для получения поддержки дальнейших инициатив со стороны руководства. Ниже приведен детальный пример того, как компания Harrah’s Entertainment смогла постепенно выстроить инфраструктурный Эмпайр-стейт-билдинг в отрасли азартных игр.

вернуться

54

Benaroch M., Jeffery M., Kauffman R., Shah S. Option-based risk management: A field study of sequential information technology investment decisions // Journal of Management Information Systems. 24 Feb. 2007. P. 103–140.

вернуться

55

Wixom B., Watson H. An empirical investigation of the factors affecting data warehousing success // MIS Quarterly. 25 (1) March 2001. P. 17–41.

61
{"b":"430895","o":1}