|
|
  |
Главная страница / Архитектура отрасли Втора жизнь корпоративных данныхOсознание того, что сбор, хранение и аналитическая обработка разрозненной информации представляет собой совершенно отдельную, самостоятельную задачу, принципиально отличную от оперативной обработки информации (OLTP), привело к созданию концепции Хранилища данных предприятия (Data Warehouse). В 1990 году Билл Инмон, автор идеи создания хранилищ данных, представил свою концепцию. Сегодня, десятилетие спустя, хранилища данных перестали быть теорией и получили самое широкое применение во всех индустриях, где работа невозможна без использования информации. За последние несколько лет создание хранилищ данных стало доминирующим подходом к организации и использованию информации в рамках систем поддержки принятия решений. Конечно, данные, накопленные в автоматизированных системах (таких, как управление персоналом, бухгалтерия и т. д.), использовались и раньше. Но существовал целый ряд проблем, неразрешимых с помощью применявшихся технологий. Примером может служить генерация отчетов из разных источников, содержащих связанные, но несовместимые данные. Хранилища данных позволяют разрешить подобные проблемы. Итак, специалисты называют, по крайней мере, три причины для построения корпоративного хранилища данных. Во-первых, временные и финансовые затраты на получение ответов значительно сокращаются, если запросы обращены не к разрозненным источникам, содержащим неструктурированную разнородную информацию, а к хранилищу, где данные хранятся в подготовленном для аналитической обработки виде. Во-вторых, построение хранилища способствует интеграции данных, хранящихся во всех приложениях, используемых в компании. В-третьих, в отличие от традиционных приложений, где практически не используются накопленные исторические данные, хранилище данных является наиболее оптимальным местом для «складирования» исторических данных. Без этих данных невозможен статистический анализ прошедших событий с целью прогнозирования стратегий на будущее, невозможна работа систем управления отношениями с клиентами (CRM) и других систем, жизненно необходимых компании в современных условиях. Анализ маркетинговых кампаний Точное определение целевой аудитории маркетинговых кампаний, анализ ее реакции на эти кампании – основные условия перехода от массового маркетинга к массовой кастомизации, то есть такой стратегии, при которой предложение компании на рынке формируется, исходя из детально изученных потребностей клиента. Большинство организаций проводит множество маркетинговых мероприятий, направленных на продвижение различных продуктов на рынок. Анализ результатов этих кампаний позволяет организации глубже познать весь процесс (начиная с определения целевых аудиторий до изучения их реакции), а также оценить эффективность маркетинговой активности с точки зрения затраченных на ее осуществление средств. Анализ клиентских профилей Этот вид анализа предоставляет возможность разделить всю массу клиентов на множество микросега идет процесс разделения рынков на более мелкие секторы, такая дифференциация клиентской базы по сегментам становится важной составляющей маркетинговой стратегии. И особенно в случаях, когда сегменты имеют отчетливо выраженные отличительные характеристики. Анализ лояльности клиентов Одно из непременных условий стабильного развития компании – сохранение клиентской базы. Анализ лояльности клиентов осуществляется с различных точек зрения, таких как продолжительность сотрудничества, спектр используемых услуг и продуктов, а также влияние на лояльность клиента демографических, географических и других факторов. Анализ продаж Анализ продаж с таких точек зрения, как реализация различных продуктов, категорий и групп продуктов, продажи по регионам и временам года и др., дает компании интегрированную перспективу результатов продаж. Кроме того, менеджеры по продажам, основываясь на соответствующей информации, могут изучить основные тенденции и модели развития ситуации. Анализ обслуживания клиентов Клиенты взаимодействуют с компаниями, наводя справки, обращаясь с различными запросами, вносят свои предложения и т. д. Информация о таких контактах дает возможность изучить поведение клиентов и оценить достижения компании в сфере обслуживания клиентов. Вероятная степень удовлетворенности или неудовлетворенности клиентов может быть определена путем анализа истории взаимодействия клиента и компании, предоставляющей услуги. Анализ эффективности работы компании Анализ эффективности работы компании позволяет обеспечить ее руководство информацией, необходимой для стратегического планирования и формирования маркетинговой политики. Для анализа эффективности работы телекоммуникационной компании используются данные обо всех осуществляемых транзакциях, главная составляющая которых – звонки клиентов. Корреляция информации об изменениях трафика с данными об использовании различных продуктов компании представителями разных сегментов клиентской базы – ключ к пониманию поведения клиентов, в том числе причин, по которым клиенты решаются на смену провайдера. Могут быть проанализированы различные категории звонков (местные и междугородные, краткие и продолжительные и т. д.). Информация о колебаниях трафика может быть соотнесена с информацией о других объектах (например, определенном коммутаторе) и событиях (скажем, проведенной рекламной кампании). Также можно проанализировать интегрированную информацию о счетах в разрезе разных продуктов и услуг. Анализ прибыльности Для формирования правильной ценовой политики, определения поощрительных скидок, распределения ресурсов и разработки стратегии для любой организации чрезвычайно важно иметь правильное представление о собственной прибыльности. При этом прибыльность – весьма многогранное понятие, которое можно рассматривать с точки зрения всей организации, отдельного канала сбыта, конкретного продукта или каству компаний также необходимо оценивать валовую, чистую прибыль и т. д. Для телекоммуникационных компаний жизненно необходимо иметь информацию о прибыльности различных областей своего бизнеса (прежде всего для того, чтобы определять оптимальную структуру цен и тарифов). Также обязательно следить за тем, как используется сетевое оборудование, какой доход приносят те или иные участки сети и различные продукты компании. Не менее важно владеть информацией о прибыльности разных клиентских секторов (например, самые крупные контракты, малые/средние предприятия и физические лица). Кто выступает в роли заказчика проекта? Наличие в компании бизнес-спонсора проекта по созданию хранилища данных – одно из самых важных условий для его удачного осуществления. Под бизнес-спонсором в данном случае понимается сотрудник или группа сотрудников, входящих в состав высшего руководства компании и хорошо ориентирующихся в том, какие цели стоят перед компанией и каким образом хранилище данных может способствовать их достижению. Как показывает практика, вопрос об использовании хранилища данных для решения стратегических задач компании может быть инициирован техническими специалистами компании. Однако без заинтересованности и непосредственного участия руководства компании проект заранее обречен на провал. Это обусловлено тем, что конечными пользователями хранилища данных как инструмента, позволяющего принимать эффективные тактические и стратегические решения, выступают обычно руководящие сотрудники компании и/или ее подразделений. И оттого, насколько они будут удовлетворены результатами проекта, зависит его успех. Следовательно, формулировка целей и ожидаемых результатов проекта должна осуществляться при непосредственном их участии. На этапе формулирования требований к системе поддержки принятия решений участвующим в проекте техническим специалистам принадлежит чрезвычайно важная роль. Их задача – детально разъяснить, какая информация необходима от бизнес-спонсора и какова доля его участия в проекте по созданию хранилища данных. Роль бизнес-спонсора (то есть, по сути, конечных пользователей) в проекте состоит главным образом в определении требований к данным, предоставлении описаний данных и данных, которые будут помещаться в хранилище для аналитической обработки и т. п. Кому отводится роль исполнителя? Построение хранилищ данных требует профессиональных знаний и опыта, совершенно отличных от тех, что накапливаются при проектировании обычных оперативных (OLTP) систем. Для анализа данных используются специальные модели – многомерные, денормализованные, "звезды", "снежинки" и пр. Понимание того, какая модель самая оптимальная для компании, какой именно анализ дает наибольшую отдачу, приходит постепенно в результате многих итераций разработки. Как показали проекты по созданию хранилищ данных, осуществленные нашими клиентами (в том числе в России), эта задача вполне можезации. Конечно, обязательное условие в этом случае – высокая квалификация специалистов и их желание участвовать в такого рода проекте. Стоит заметить, что проект потребует от них определенных усилий, которые выходят за рамки привычной для них предметной области. Не будет преувеличением сказать, что участие в подобном проекте позволяет техническим специалистам не только подняться на качественно новый профессиональный уровень, но и занять более высокую позицию в иерархии компании. В то же время руководство должно понимать, что участие в проекте такого уровня сложности, а также дальнейшее сопровождение и поддержка хранилища данных не могут быть поручены сотрудникам в качестве дополнения к уже имеющимся обязанностям, поскольку потребуют от них полной отдачи. Немаловажным фактором является также поддержка и сопровождение проекта со стороны выбранного поставщика информационных технологий. Сколько стоит построить хранилище данных? До недавнего времени проекты по созданию хранилищ данных справедливо относились к разряду очень дорогостоящих. Даже в странах с благополучной экономической ситуацией далеко не все организации могли позволить себе решения из этой области. Из чего же складывалась такая высокая стоимость проекта? Большие объемы данных (десятки и сотни гигабайт) Аналитика строится на основе первичной информации. Например, для телекоммуникационных компаний – это запись информации о всех телефонных звонках, для банков – запись всех транзакций банковских клиентов и т. д. Объем данных о всех звонках многих тысяч клиентов телекоммуникационной компании за год может составить сотни гигабайт. Эти данные должны быть подготовлены для анализа, то есть проиндексированы, возможно, проагрегированы, наложены на денормализованную модель, что в традиционных хранилищах приводит к так называемому «взрыву» данных и увеличению их объема в 3–10 раз по сравнению с исходным. При этом предъявляются высокие требования к быстродействию и надежности систем хранения, что означает использование дорогих высокопроизводительных дисковых систем, как правило RAID-массивов. Современный надежный RAID-массив высокой производительности, предназначенный для хранения 100 GB данных, может стоить до 100 тыс. долл. Требования к мощности компьютерных систем Обработка аналитических запросов в хранилище данных должна производиться в разумный период времени. Как говорится, хороша ложка к обеду. Это означает, что компьютерных ресурсов должно быть достаточно, чтобы, к примеру, выполнить поиск и выборку по соединению из нескольких таблиц в десятки миллионов записей в пределах одного часа. Характерно, что сложность аналитических запросов, циркулирующих в современных хранилищах данных такова, что некоторые из них не выполнимы на маломощных компьютерных системах. Как правило, для хранилищ используются мощные многопроцессорные системы класса RISC Unix, часто в кластерной конфигурации, долларов. Архитектура хранилищ данных Хранилище данных – это сложная программная система. Архитектуру хранилищ данных составляют следующие компоненты. • Средства извлечения данных из различных баз данных, унаследованных систем и таблиц. • Средства трансформации и очистки данных. Точность существующих данных доставляет немало хлопот организации. Поэтому, перед тем как поместить данные в хранилище, их необходимо очистить. • Программное обеспечение базы данных. Как правило, это высокопроизводительная РСУБД, используемая для структуризации и хранения информации. • Средства для соединения источников данных с хранилищем и клиентов с сервером. Кроме этого, необходимы специальные программные средства проектирования хранилища, средства работы с репозитарием метаданных и собственно средства оперативной аналитики, или OLAP-средства. Все это сложное специальное программное обеспечение, стоимость которого также может исчисляться десятками и сотнями тысяч долларов. Высокие трудозатраты Как уже отмечалось, для успешного осуществления проекта по построению хранилища данных необходимо создание проектной группы, состоящей из высококвалифицированных технических специалистов. Это необходимо учитывать при составлении бюджета проекта. Можно ли снизить стоимость проекта? На сегодняшний день существует (в том числе при реализации проектов в России) ряд подходов и технологий, позволяющих, во-первых, существенно снизить стоимость проекта по созданию хранилища данных, а во-вторых, «смягчить» нагрузку на бюджет компании-заказчика благодаря «щадящей» поэтапной схеме осуществления проекта и расчетов. Вот почему можно утверждать, что проекты по созданию хранилищ данных перестали принадлежать к разряду элитарных. Уменьшение объема данных Перечисляя статьи расхода, из которых складывается стоимость проекта по созданию традиционного хранилища данных, в первую очередь мы упомянули о высокой стоимости дисковых массивов, необходимых для хранения данных. Их объем, как правило, существенно увеличивается по сравнению с объемом исходной информации. Первоисточником явления, получившего название «взрыв данных», послужило то, что в качестве баз данных в хранилищах обычно используются обычные РСУБД, изначально создававшиеся для оперативной обработки информации (OLTP). Несмотря на то что характеристики этих СУБД на разных этапах были дополнены характеристиками, позволяющими использовать их для хранения данных с целью анализа, архитектура этих СУБД изначально не была рассчитана на такое применение. Существуют СУБД, которые разрабатывались специально для использования в хранилищах данных. Они обеспечивают эффективные хранение и обработку многомерных моделей данных, но, к сожалению, не позволяют избежать взрыва данных, который в этих СУБД обусловлен самой природой многомерной модели. Компания Sybase позволяет решить эту проблему, предлвоей архитектуры. Она в корне отличается от архитектур как многомерных, так и традиционных реляционных СУБД. Благодаря принципиально иному физическому дизайну Sybase Adaptive Server IQ при переносе данных в хранилище их объем не увеличивается. Более того, происходит «сжатие» данных на 10% – 60% по сравнению с их исходным объемом и в 3–10 раз по сравнению с объемом тех же данных, переведенных для анализа в многомерную модель на традиционной СУБД. Так, «сжатие» данных в хранилище одного из наших российских клиентов составило 30%. Поэтапная реализация проекта Использование подхода, при котором реализация проекта подразделяется на этапы и в таком же порядке производится его финансирование, значительно облегчает осуществление проекта такого масштаба даже для не самых крупных компаний. Существует еще одна причина, с учетом которой клиентам рекомендуется разрабатывать план поэтапной реализации проекта хранилища данных. Одним из первых пунктов значится создание пилотного макета хранилища данных, масштабируемого затем до нужных размеров. Как бы хороши ни были технологии, применяемые для создания хранилищ данных, не скоро еще наступит день, когда такие проекты можно будет назвать заурядной задачей. Выполнение «пилота» позволит клиенту приобрести необходимый опыт и отработать его на сравнительно небольшой задаче, не рискуя при этом крупными инвестициями. В то же время пилотный макет хранилища позволяет решать реальные задачи и служит для руководства убедительным аргументом в пользу необходимости создания хранилища данных. Залог успешной реализации проекта Согласно утверждениям аналитиков, около 60% проектов по созданию хранилищ данных оканчиваются неудачей либо итоги их реализации не приносят ожидаемых результатов. Это связано со сложностью и спецификой таких проектов, а также с тем, что компании зачастую просто не готовы к их осуществлению. Удачная реализация проекта требует соблюдения целого ряда условий как технологического, так и организационного характера. Еще раз напомним некоторые условия успешного осуществления проекта по созданию хранилища данных: • наличие в организации бизнес-спонсора проекта; • четкая формулировка задач, для решения которых предназначено хранилище данных; • наличие квалифицированного персонала для осуществления проекта; • выделение адекватных проекту средств; • правильный выбор информационных технологий. При этом данный перечень следует дополнить. В частности, предстоит рассмотреть аспекты, о которых мы еще не упоминали в данной статье. Качество данных, используемых в хранилище Данные, используемые в хранилище, должны отвечать следующим жестким требованиям: точность, целостность, непротиворечивость, актуальность, полнота и целому ряду других. Поскольку данные, хранящиеся в информационных системах компании, как правило, лишь в какой-то мере соответствуют перечисленным требованиям, то накануне и преобразованию этих данных. Кроме этого, конечный результат и достоверность информации, полученной после аналитической обработки данных, зависят от того, какие данные были помещены в хранилище. С одной стороны, не все данные из OLTP-систем понадобятся для получения нужной информации. С другой стороны, вполне вероятно, что для эффективного анализа необходимо будет помещать в OLTP-систему для последующего переноса в хранилище такую информацию, которая раньше не была нужна, не аккумулировалась и не фиксировалась. Например, для эффективной работы CRM-системы может понадобиться такая информация о клиентах, которая раньше не представляла интереса для вашей компании. Так, например, один из наших клиентов (российская финансовая компания) выразил желание построить систему CRM, в частности систему анализа лояльности клиентов. Но, как выяснилось, компания не располагала ни демографической, ни социальной информацией о клиентах, необходимой для этого вида анализа. Сбор такой информации – задача, которую компании необходимо решить. Один из вариантов сбора подобной информации – розыгрыш призов среди своих клиентов с обязательным анкетированием участников. Компьютерная грамотность будущих пользователей хранилища Пользоваться хранилищем данных будут отнюдь не технические специалисты, а сотрудники коммерческих, маркетинговых и других отделов, чей уровень компьютерной грамотности может существенно различаться. Чтобы прекрасно разработанный и реализованный проект не закончился крахом из-за того, что конечные пользователи хранилища не знают, как обращаться с инструментами, которые дали им в руки, необходимо на самых ранних этапах реализации проекта уточнить, на пользователей какого уровня должна быть рассчитана создаваемая система. От ответа на этот вопрос зависит выбор программных средств, которыми будет оперировать конечный пользователь (front-end). Возможно, понадобится провести определенный курс обучения. Избегайте обманутых ожиданий С самого начала проектной группе необходимо предоставлять руководству адекватную информацию относительно сроков осуществления проекта, ожидаемых результатов и, конечно, стоимости. Завышенная цена может погубить проект, не дав ему начаться. Заниженная стоимость приведет в итоге к шоку, когда придется все-таки огласить реальные суммы. И в этом случае исход также очевиден. Конечные пользователи системы должны четко понимать, какие задачи будут решены с помощью хранилища данных. При этом важно не забывать, что хранилище данных – это не панацея и не чудодейственное средство от всех «болезней» компании. Заключение В заключение хотелось бы пожелать удачи всем, кто уже приступил к реализации проекта по созданию хранилища данных, а также тем, кто только готовится принять такое решение. Остается только еще раз напомнить, что главное условие успешной реализации проекта по созданию хранилища данных – объединение усилий компании, направщего повышению конкурентоспособности предприятия. Главная страница / Архитектура отрасли |