Корпоративное хранилище данных – как его построить?

Идея отбора, интеграции и агрегации данных из огромного количества информации, которую потребляет и производит компания в своей оперативной деятельности, не нова. Она возникла под влиянием требований к качеству и оперативности обработки данных, необходимых для выработки тактики и стратегии развития компании, а также принятия повседневных управленческих решений. Мечта всех управленцев – «полная картина мира без усилий», казалось, становится возможной, если правильно собрать всю значимую для нее информацию. Подчеркнем ключевые слова – «значимую» и «правильно».

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

Такому подходу во многом способствуют и вендоры с интеграторами, предлагая построить КХД как панацею от всех бед. Необходимо сохранять значимую информацию из различных источников, используемых в компании, с учетом истории ее изменения во времени? Строим корпоративное хранилище данных! Сложности с построением отчетов? Оперативные системы не выдерживают нагрузки при формировании очередного списка транзакций? Строим специальную базу данных под отчеты – корпоративное хранилище данных! Решили создать ситуационный центр компании? Построить систему управления событиями? Создать панель руководителя? Строим КХД! Вам нужна ERP? Да вы не обойдетесь без корпоративного хранилища! Согласитесь, все перечисленные задачи разные и методы их решения не очевидны. Поэтому если фактически решаемая задача не может быть сформулирована как задача оптимизации процессов построения отчетов для конкретных пользователей в рамках указанных бизнес-функций (даже создаваемых, а не существующих), проект построения КХД обречен на провал.

Наша экспертиза

Мы настаиваем на том, что в постановке цели и задач проекта создания КХД отчеты и их потребители первичны. Перечислим 3 признака того, что компании нужно хранилище данных:

1. процесс подготовки сводного отчета для руководителя напоминает пирамиду Хеопса или, если хотите, лавину: несколько необходимых руководителю показателей превращаются на следующем уровне в необходимость собрать информацию из десятка отчетов. А они, в свою очередь, готовятся вручную на основе информации из многочисленных информационных систем и десятков Excel-файлов. Десятки сотрудников и даже целые подразделения занимаются перекладыванием цифр из одного Excel-файла в другой;
2. программисты постоянно заняты написанием новых отчетов, каждый в своей информационной системе, эти отчеты облегчают жизнь на нижнем уровне пирамиды, но не выше. Они стремительно устаревают, т.к. меняются потребности руководства в информации. Соотношение полезный эффект/затраты на разработку для одного отчета невысоко;
3. сводная отчетность появляется редко и «посмертно», например, за прошедший месяц в середине следующего. Механизм «пирамиды» требует значительного времени на проворачивание «шестеренок», нельзя получить отчет «сегодня за вчера».

Три признака того, что проект по построению хранилища задуман и организован плохо и, скорее всего, окончится неудачей:

1. вы не знаете, какие отчеты хотите получать из хранилища, анализ какой информации в каких разрезах нужен;
2. вы не знаете, какие данные есть в системах-источниках, по системам нет документации, описывающей структуры данных или хотя бы принципы работы пользователей в них;
3. вы хотите «всё и сразу»: в рамках одного первого проекта свести в единое хранилище данные из полусотни систем, эксплуатируемых компанией в несколько тысяч, а то и десятков тысяч человек.

Рецепт правильного КХД

Теперь возвращаемся к основному вопросу, возникающему при построении КХД: как же определить и собрать правильную коллекцию данных для решения задачи, поставленной компанией? Для более точного ответа еще раз вернемся к определению, что же такое корпоративное хранилище данных и какие системы являются его основными потребителями.

Нам не раз приходилось слышать мнение, что КХД может заменить существующие информационно-аналитические системы компании. В большинстве случаев это совсем не так, однако доля истины здесь есть. Дело в том, что работы по созданию хранилища заключаются в отборе необходимых данных, выстраивании между ними правильных связей и зависимостей (создании каркаса хранилища – модели данных), разработке механизмов их обработки, наполнения справочников и объединении всех этих частей в единый процесс. КХД – это прежде всего процесс черновой аналитической обработки оперативной информации из систем компании: генерация витрин и киосков данных, необходимых для более высокоуровневой аналитики. По сути, КХД является тем самым ситом, которое выполняет функцию отделения значимых данных от второстепенных с помощью модели.

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

Наша экспертиза

Три признака того, что КХД не спасет:

1. значительная часть необходимых в хранилище данных не «прописана» ни в одной информационной системе, а существует только в виде Excel-файлов, которые ведут отдельные сотрудники на своих локальных компьютерах. Данные из Excel, конечно, можно загрузить в хранилище, но есть моменты:

• возникает проблема справочников: их нет. Например, данные на разных листах или в разных файлах, может быть, и относятся к одному клиенту, но об этом знает только человек. Сотрудник понимает, что «ОАО Мечта» и «Мечта г. Бердянск» – один и тот же клиент, а системе это не очевидно;
• проблема формата: он меняется (а процедура загрузки без программиста – нет). Так просто добавить еще пару столбцов и желательно не в конец таблицы, а там, где удобнее – в середину… А еще можно под каждый месяц добавлять новый лист и называть их то «январь 2013», то «01.2013», то «янв.13»;
• есть и другие, более «технические» проблемы, например, проблема уникальных идентификаторов строк данных, но об этом в другой раз;

1. данные в основном находятся в нормальных информационных системах, вот только сами эти системы ничего друг о друге не знают. В каждой из них – свой справочник контрагентов, городов, номенклатурных позиций, а нужны сводные отчеты по данным из систем в разрезе контрагентов, городов, номенклатурных позиций… Здесь сначала нужно озаботиться синхронизацией справочной информации, т.е. нужен MDM (Master Data Management) или НСИ (управление нормативно-справочной информацией);
2. информационные системы с данными для хранилища представляют собой «черные ящики». Данные в них накапливаются, но не понятно, как вытащить их наружу, и нет возможности доработать систему. Чуть более мягкий вариант – вытащить данные все-таки можно, но каждый раз вручную, с помощью специально обученного человека. Актуальность и полнота данных в хранилище здесь будут завязаны на человеческий фактор.

Каждой отрасли – по хранилищу?

Создание модели данных для эффективной работы интеллектуальных информационных систем – это практически всегда искусство. Правильно определить структуру, в которую с высокой вероятностью уложатся все данные, необходимые для обеспечения работоспособности отдела или подразделения компании, – процесс, в принципе, непростой. А если необходимо определить не просто модель, а создать базис для правильного принятия решения? Определить наиболее значимые параметры, влияющие на качество работы, прибыльность бизнеса и т.д.? Удалить из будущей модели второстепенную информацию, усложняющую восприятие общей картины? Задача кропотливая, длительная и, на первый взгляд, близка к невыполнимой, не правда ли? Не у каждой компании найдутся специалисты нужной квалификации, время на выполнение такой задачи, анализа и т.д. А хранилище нужно всем. Именно поэтому уже достаточно давно популярна тема создания отраслевых корпоративных хранилищ.

Вендоры наперебой предлагали и предлагают уже готовые КХД, созданные под конкретный бизнес: банки, транспорт и т.д. Заманчиво, не правда ли? Похожесть бизнеса разных компаний одной отрасли в первом приближении не вызывает сомнения. Одинаковые классы учетных систем, похожие отчеты, задачи, требования… Казалось бы, проще использовать чужой опыт по очистке и систематизации данных, подстроить свои информационные системы под готовое, почти коробочное решение.

Однако на деле применение чужой универсальной модели данных в правильно выстроенном проекте создания КХД не отменяет этап работ по выработке требований потребителей информации и конечных пользователей интеллектуальных систем. И, в конечном итоге, по адаптации коробочного решения под собственноручно выстраданную модель данных.

Более того, мнимая «готовость» коробочных решений в виде отраслевых хранилищ чаще всего и толкает компанию к воплощению глобальной цели – интеграции всех данных из всех имеющихся систем. Потребности пользователей размываются, задача вновь становится неподъемной, и проект проваливается.

Наша экспертиза

Как правильно реализовать проект по построению КХД? Разумнее будет начать с малого – выделить пилотный участок (набор информационных систем, обслуживающих какой-либо бизнес-процесс), желательно слабо связанный с другими, и на нем потренироваться, набить шишек как на построении модели данных, так и на определении систем-источников и потребностей конечных пользователей. Когда пилотный участок заработает и даст первые результаты, вы сможете запланировать развитие и постепенный охват всей деятельности компании.

Резюмируя все вышесказанное, можно констатировать, что проект создания и внедрения КХД, безусловно, будет одним из самых непростых в ИТ-истории компании. Дело в том, что данный процесс повлечет за собой перетряхивание и, возможно, повторное изучение унаследованных и приобретенных баз данных и информационных систем, анализ исторических данных и даже реинжиниринг сквозных бизнес-процессов. Неизбежно прохождение всех шагов, необходимых для создания модели данных компании, во многих случаях уникальной. Без этой фазы дальнейшее развитие ИТ-систем как эффективного инструмента развития бизнеса невозможно.