Энди Хэйлер (Andy Hayler), перевод: Intersoft Lab,
19 Январь 2005 г
Пару лет назад у одной крупной европейской компании, специализирующейся в области энергетики, появилась возможность последовательно проанализировать рентабельность любой коммерческой операции. Ранее такой анализ был трудновыполним, поскольку в каждой стране существовала своя схема распределения затрат. Поэтому полной неожиданностью для компании стала ситуация, сложившаяся в одной стране: выяснилось, что в ней присутствует большое число низко доходных, единичных операций. Поясним, что данная ситуация нетипична для продавца, потому что, как правило, для него массовые продажи менее прибыльны по сравнению с низким объемом сделок. Действительно, покупатель может потребовать скидку, если он покупает вместо десяти единиц какого-либо изделия тысячу. Таким образом, в качестве ответной меры компания повысила цены на всех региональных рынках. И хотя в итоге объем продаж немного снизился, поскольку были потеряны некоторые высоко доходные операции, совокупный доход повысился на 25%. Стоит отметить, что проведение упомянуто выше анализа стало возможным благодаря использованию федеративного корпоративного Хранилища данных (federated enterprise data warehouse).
Пожалуй, уже не нужно доказывать, как важно для многофилиальных международных корпораций наличие согласованной управленческой информации, необходимой для четкого понимания того, как функционирует бизнес. К сожалению, сегодня очень немногим компаниям удалось достичь высокого уровня информационного обеспечения. Обычной подход к улучшению информированности о бизнес-операциях - проведение стандартизации структуры отчетности и модели данных "сверху вниз".
Однако, с практической точки зрения стандартизация бизнес-структур оказывается для большинства организаций исключительно нецелесообразной. Действительно, для проведения такой операции требуется слишком много средств, времени, наконец, данный подход может быть просто нереализуем, поскольку в любом бизнесе присутствует чрезвычайно мало простых и однообразных областей, которые не потребовали бы учета местной специфики.
Если, например, можно стандартизировать коды валют по всей корпорации, введение полностью стандартизированной линейки продуктов редко оправданно, а в некоторых случаях - даже нежелательно. Так, например, уровень продаж местных кондитерских изделий в Японии вряд ли привлечет внимание руководства, однако насколько успешно продаются все продукты данной товарной категории, вероятно, вызовет интерес.
Поэтому даже если стандартизацию и удалось бы полностью реализовать на практике, необходимость обеспечения согласованности лишала бы филиалы компании возможности приспосабливаться к условиям местного бизнеса и происходящим на нем изменениям. Такая ситуация чревата "возникновением войны" между центральным офисом и местными отделениями, результатом которой является разработка "теневых" инструментов Business Intelligence, используемых наряду с решениями головного офиса, куда необходимо предоставлять данные. С учетом того, что центральная система неспособна отвечать потребностям пользователей, сотрудники филиалов не стремятся тщательно проверять качество данных, и поэтому существует опасность, что данные, отправляемые в головной офис, могут оказаться ошибочными. Очевидно, что проблема "противостояния центральный - местный офис" должна быть каким-то образом разрешена, однако лишь очень немногим компаниям это под силу. Главное отличие этих "прозорливых" компаний от других состоит в том, что они воспользовались подходом, в основе которого лежит создание "федеративной" модели Хранилища данных. В соответствии с данным подходом, с помощью иерархии связанных Хранилищ данных можно обмениваться данными, бизнес моделями и структурами отчетности, благодаря чему можно, с одной стороны, осуществлять общий контроль и предусмотреть определенную степень стандартизации, а, с другой - позволить региональным отделениям сохранить автономность и учесть местную специфику. Федеративное Хранилище данных состоит из ряда экземпляров Хранилищ данных, которые функционируют на полуавтономной основе и, как правило, организационно или географически разнесены, однако могут рассматриваться и управляться как одно большое Хранилище данных.
Поскольку построение федеративного Хранилища данных можно осуществлять постепенно - "шаг за шагом", при его создании разумно воспользоваться методом "начинай с малого, планируй в глобальном аспекте". Такой подход существенно снижает риск неудачи при глобальном развертывании системы, поскольку каждое локальное Хранилище данных меньше по масштабу, незамедлительно отвечает местным требованиям и может управляться сотрудниками регионального бизнес-подразделения.
К сожалению, неверное использование термина "федеративное Хранилища данных" и непродуманные попытки приписать данной технологии несвойственные ей свойства (присутствующие, главным образом, в "пылком воображении" продавцов программных продуктов), включая "виртуальное" Хранилище данных, изрядно подпортили ее репутацию. Рассмотрим, например, "виртуальное" Хранилище данных. В этом случае глобальное Хранилище данных не хранит копию всех данных, наоборот, данные находятся в оперативных системах, которые их создают. В центре такой "паутины" находится монолитное глобальное Хранилище данных, которое должно тем или иным образом отвечать на бизнес-запросы - разбивать запрос, обращаться с ним к каждой исходной системе и "магическим образом" объединять результат. Понятно, что любая попытка применить этот подход обречена на провал, а любое упоминание о нем может лишь вызвать улыбку у любого, кто располагает серьезным практическим опытом. Действительно, объединение результатов запроса является технически сложной задачей, но даже в случае ее разрешения, распределенные запросы предъявят непредсказуемые и, следовательно, недопустимо высокие требования к вычислительным ресурсам оперативных систем.
Что действительно работает очень успешно - так это группа, или "федерация", Хранилищ данных, каждое из которых хранит копию базовой бизнес-модели и общие основные данные (common master data), причем каждое Хранилище данных более высокого уровня содержит итоговые транзакционные данные более низкого уровня.