Как правило, внедрение BI-решения на предприятии — шаг стратегический. На II международном форуме «Business Intelligence — 2008», который проводила фирма AHConferences, первая сессия так и называлась: «Business Intelligence как элемент стратегии компании». Однако иногда можно значительно улучшить бизнес-аналитику организации, вообще не затрагивая пользователей во время проекта. В компании «Ингосстрах» был проведен именно такой проект, заказчиком и спонсором которого выступил исключительно ИТ-департамент. Бизнес же только получил готовые результаты.

«Ингосстрах» — компания большая, пользователей в системе много, и они, по словам Максима Серпухова, начальника отдела разработки отчетности, любят анализировать. Чтобы предоставить им необходимое средство анализа, около трех лет назад было создано хранилище данных на базе СУБД Oracle. Отчеты при этом реализовывались в виде витрин данных. В качестве OLAP-средства, как это часто бывает, использовалось приложение Microsoft Excel, в котором с помощью инструментария pivot table строилась нерегламентированная отчетность. За годы работы системы накопилось около двух тысяч файлов-отчетов, из которых примерно половина использовалась в течение последнего года, а половина из этой половины — в последнем квартале, что составляет около пятисот отчетов. Учитывая столь внушительную цифру, ИТ-департамент создал для управления отчетностью приложение, чтобы контролировать эту работу.

Чем старый друг хуже

Конечно, в такой ситуации без проблем обойтись не удалось. Максим Серпухов без тени иронии рассказал, что хоть он и считает Microsoft Excel отличным OLAP-средством, в компании со временем поняли, что его использование ставит серьезные препоны на пути развития. Например, один из основных отчетов, предназначенный для анализа общей ситуации и стимулирования сотрудников, состоит из шест­надцати файлов, которые содержат данные о двух годах работы, разбитые по кварталам и регионам. Не удивительно, что несмотря на постоянные программные обновления система давала сбои. «Общение с Excel на программном уровне — это иногда шаманство, а не программирование», — шутит Максим Серпухов. Не хватало и средств разграничения доступа внутри отчетов. Достаточно было уже того, что использовалась файл-серверная архитектура — это создавало высокую нагрузку на сеть, повышало требования к производительности рабочих станций.

Постановка задачи

Всё это со временем подвело ИТ-департамент к тому, что необходимо более совершенное OLAP-средство. И было принято решение применить, как выразился Максим Серпухов, «низкоинвазивную хирургию» — попытаться затронуть только «болезненный участок», то есть избавиться от наиболее узкого места. В итоге единственной задачей, которую поставил перед собой ИТ-департамент, была замена Microsoft Excel другим инструментом. «Мы хорошо понимали, что для наших любимых пользователей уход от Excel уже является культурным шоком, а если менять что-то еще, то это не каждый может выдержать», — отметил глава проекта со стороны заказчика.

Когда решение было принято, возник вопрос об организации проекта, а также о выборе продукта и партнера. Поскольку задача носила исключительно технический характер, решено было не затягивать процесс подготовки отчетности — отказаться от сбора требований и проведения интервью с пользователями, ведь нужные данные были уже известны. Более того, сочли, что бизнес вообще не стоит вовлекать в проект — его заказчиком в данном случае выступал сам ИТ-департамент. Процесс выбора партнера был сведен к тому, что нескольким претендентам предложили реализовать один из OLAP-кубов. В результате был выбран продукт Cognos, а партнером стала компания КРОК.

Еще одной особенностью проекта стали его сжатые сроки — компании нужен был четкий результат уже к началу нового отчетного периода. Следствием этого явилось разбиение проекта на несколько этапов, каждый из которых представлял собой самостоятельный подпроект, включавший в себя все фазы стандартного проекта. При этом на выходе такого подпроекта нужно было получить конечный результат, решающий определенную бизнес-задачу, который сразу передавался пользователям для опытной эксплуатации.

Так как пользователи в проекте задействованы не были, в нем участвовало всего четыре человека — по два с каждой стороны (заказчика и исполнителя), а фаза постановки задачи и сбора требований была сокращена до двух-трех недель. За это время следовало определить объем работ и все предметные области — отчеты, OLAP-кубы и т. д. Как только поэтапный план работ был написан, участники проекта приступили к его реализации.

Переосмысление задачи

За три месяца с момента старта проекта были реализованы и переданы в опытно-промышленную эксплуатацию три довольно крупных и показательных куба. По словам Максима Серпухова, наиболее активные пользователи — около двадцати человек — хоть и строили серьезные отчеты в старой системе, все же с интересом стали пробовать и новые OLAP-кубы.

В последующие два месяца в новой системе было реализовано еще три куба. Но здесь первоначальный план несколько изменился. «Мы поняли одну замечательную вещь, — поясняет Максим Серпухов: в Cognos понятия “просто и быстро” и “правильно” представляют собой одно и то же. Создав три куба, мы выяснили: для того чтобы сделать остальные тринадцать, надо остановиться, построить классическую модель данных, выделить все справочники, определить правила их заполнения и потом уже в этой среде быстро, гораздо быстрее, нежели в первом варианте, построить все остальные отчеты».

«Сдав первый этап, мы поняли, что точку в конце этого подпроекта мы поставить не можем, — говорит Максим Андреев, руководитель направления бизнес-приложений компании КРОК. — Формально все обязательства мы выполнили: сделали все кубы, которые обещали, провели все необходимые процедуры. Но по мере движения вперед происходит некое переосмысление задач, появляются новые ожидания, новые требования, новое видение. И мы постоянно немного откатываемся, что-то доделываем, что-то перерабатываем».

В результате архитектура системы была изменена так, что пользователи смогли работать не только с агрегированными, но и с детальными данными. Теперь если аналитик работает с многомерным кубом, оперативно, в течение пяти секунд получая нужные ему данные, и ему необходима их детализация, он может прямо из инструмента работы с OLAP-кубами перейти в плоский отчет, который напрямую работает с таблицами хранилища данных.

Скорость обработки

Чтобы проследить, какие преимущества получила компания, можно рассмотреть пример построения одного из OLAP-кубов — автострахования. Вот его параметры: данные за 8 лет; 36 измерений; 27 показателей; максимальное количество точек измерения — порядка 10 000 (города); исходные данные после предварительной агрегации в Oracle — примерно 21—22 млн. записей; размер куба — около 1,3 Гб. В то же время OLAP-куб обрабатывается на стандартном оборудовании — однопроцессорном сервере с 4 Гбайт оперативной памяти. И все это укладывается в стандарты OLAP-технологий — совершение операций занимает не более шести секунд. Этого удалось достичь благодаря двум моментам.

1. Оптимизация задач с точки зрения предмета. Перво­на­чаль­но существовала витрина данных, которые просто передавались в куб. От этой схемы отказались, выделив справочники и фактовые таблицы, что позволило существенно сократить время построения куба.

2. Техническая оптимизация. В первую очередь эта часть работы включала разнесение различных компонентов системы по физическим дискам. Основная идея такого преобразования заключается в том, чтобы операции чтения-записи выполнялись параллельно на разных дисках. Сюда входило, например, разнесение операционной системы и временных файлов, разнесение приложения и данных. Еще одна существенная деталь — тонкая настройка самого инструмента Cognos для построения OLAP-кубов: работа с кэшем, партиционирование и ряд других задач. Кроме того, задачу предагрегации данных решено было реализовывать в хранилище. Хотя изначально этого не предполагалось, тесты показали, что СУБД Oracle с ней справляется лучше.

В результате всех этих преобразований построение указанного OLAP-куба, которое раньше занимало девять часов, теперь требует часа с небольшим.

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

Итоги и перспективы

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

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

«Мы перевалили за экватор и в будущее смотрим с уверенностью и надеждой, — говорит Максим Серпухов, — потому что мы уже четко понимаем, что происходит, как это будет развиваться. У нас впереди еще десять кубов, а также ужесточение требований по безопасности. Я не могу сказать, что эти требования сильно превысили стандартные возможности Cognos, но мы приняли решение использовать возможности программирования в этой среде, поэтому в ближайшие планы входит использование языка для построения сложной системы безопасности».