ассортиментных позиций, которые сравнительно легко складировать и транспортировать). Однако когда он по мере роста стал продавать и товары иного рода, архитектуру системы менять не пришлось – все было уже запланировано заранее.
Перенести данные или изменить архитектуру для нового хранилища?
В 1995 году Continental Airlines имела 45 различных баз данных. Их объединение в централизованное хранилище позволило экономить по 5 миллионов долларов в год. Экономия была обусловлена рядом факторов: меньшее количество контрактов с поставщиками баз данных, сокращение времени на переговоры с ними, меньшая площадь для оборудования (а соответственно, сокращение накладных расходов). Однако, что важнее всего, для обслуживания этого «монстра» требовалось меньше администраторов. Объединение различных баз данных в единое хранилище называется консолидацией витрин данных; понятно, за счет чего складывается экономия в рамках этого процесса{53}. Однако здесь возникает дилемма: переносить данные в текущем формате или изменять их архитектуру для новой системы?
Миграция данных означает, что вы перекачиваете данные из существующих мелких баз в большое хранилище. Если у вас есть 50 независимых витрин данных, внутри единого консолидированного хранилища разместятся 50 независимых баз данных. Это приведет к снижению расходов на обслуживание системы, но сами данные никак не изменятся. Однако в этом случае вы, как и раньше, не сможете дать ответы на важные вопросы, стоящие перед компанией.
Почему это важно? Многие руководители маркетинговых подразделений в разговорах со мной жаловались, что новое хранилище данных в их компании не дает им возможности получить ответы на самые простые маркетинговые вопросы. В чем же была проблема? Отдел IT увлекся идеей экономии расходов за счет консолидации данных в одном крупном хранилище, но не обратил внимания на суть проблем бизнеса: чтобы получить целостную картину, необходимо было изменить архитектуру данных.
Новая архитектура предполагает необходимость продумать все сложные взаимосвязи и оптимизировать модель данных так, чтобы она могла отвечать на самые важные для маркетинга вопросы. Разумеется, изменение архитектуры приводит к росту расходов, однако это с лихвой компенсируется новыми преимуществами. Однажды я рассчитал финансовые последствия двух вариантов работы (простой миграции данных или изменения архитектуры) для крупного финансового учреждения{54}. Оказалось, что решение, основанное на новой архитектуре, позволяет повысить NPV в три раза!
Что может пойти и пойдет не так (если вы не будете осторожны)
На обочине бизнеса покоятся останки масштабных IT-проектов, потерпевших крах (и проекты хранилищ данных не исключение). По оценкам Standish Group, ежегодно отслеживающей состояние тысяч IT-проектов, не менее 72 % проектов не завершаются в срок или в рамках оговоренного бюджета. Иными словами, вероятность того, что система с самого начала будет работать, как задумано, составляет всего 28 %. Что касается EDW, то здесь ситуация выглядит еще менее радужной: Барбара Уиксом и Хью Уотсон{55} обнаружили, что, по словам 55 % руководителей, новая система хранения данных не может обеспечить необходимые результаты.
Статистика выглядит удручающе: впору задуматься, нужно ли вам хранилище данных для маркетинга в принципе. Однако основные причины неудач хорошо задокументированы, и вот какие основные факторы риска были отмечены Уиксом и Уотсоном:
• Отсутствие сосредоточенности и ви?дения – общие цели усилий по развитию EDW недостаточно хорошо определены.
• Отсутствие поддержки (в том числе финансовой) со стороны высшего руководства.
• Отсутствие «борца», способного продвигать проект и обеспечивать информацию, материальные ресурсы и политическую поддержку.
• Организационная политика и культурные вопросы.
• Недостаточность ресурсов – финансов, времени и/или персонала.
• Масштабируемость решения – компании строили «дом для фермера», хотя нуждались в Эмпайр-стейт-билдинг.
• Технологии – система может быть основана на новой и незнакомой технологии, либо изначально выбрано неправильное технологическое решение.
• Отсутствие навыков – команде, занимающейся внедрением, недостает навыков и знаний для работы с системой. Для удачного запуска масштабных проектов в области EDW нужны отличный менеджер проекта и опытная команда технологов.
• Качество уже имеющихся баз данных – как ни странно, это довольно серьезная проблема (я расскажу о ней чуть ниже).
• Расчет на внешние ресурсы – зачастую работа перекладывается на плечи внешних подрядчиков, а IT-команда принимает результаты. На самом деле маркетерам может быть нужно что-то отличное от того, что предлагает подрядчик. В ряде случаев внутренней IT-команде не удается поддерживать предложенную подрядчиком систему в рабочем состоянии.
• Изменения, связанные с навыками персонала и уходом отдельных сотрудников, – иногда в разгар работы над крупным проектом уходят ключевые сотрудники. Если в работе участвует внешний подрядчик, то проблему можно решить с помощью контракта
