BI для массового использования: поиск наилучшего способа реализации

Джо Людтке (Joe Luedtke),
перевод: Intersoft Lab

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

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

Если компания впервые начинает проект, связанный с Хранилищем данных, то, несомненно, в IT-отделе найдется один или несколько сотрудников, рассматривающих либо технологию Ральфа Кимбола (Ralph Kimball) — Инструментарий жизненного цикла хранилища данных (Data Warehouse Lifecycle Toolkit), либо методику Била Инмона (Bill Inmon) — Корпоративную информационную фабрику (Corporate Information Factory). Автору статьи идея их применения кажется одновременно и ободряющей, и настораживающей.

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

Лучший выход в реальной ситуации

Как сказал Жан ла ван де Снепсшо (Jan la van de Snepscheut): «Теоретически разницы между теорией и практикой нет. А практически — есть». Стоит прислушаться к этому высказыванию. Вместо того, чтобы нацеливаться на реализацию оптимального метода, лучше постараться найти самый рациональный в данной ситуации выход, опираясь на известные методики. Фраза «лучший выход в реальной ситуации» коротка, но в ней содержатся глубокие идеи, скрытые за этими четырьмя простыми словами.

Рис. 1. Лучший выход в реальной ситуации

Все в ваших руках

Большинство пользователей прибегает к тем же методам, что и «все остальные». Но стоит задаться вопросами: уникальна ли компания в каком-то смысле? Есть ли у нее какие-либо отличительные особенности, дающие ей преимущества перед конкурентами? Если это так, действительно ли стоит применять «методы остальных», которыми пользуются конкуренты?

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

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

В долгий путь

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

Однажды автор с удивлением наблюдал, как менеджер IT-проекта настойчиво поправлял заказчика при употреблении термина «Хранилище данных». «Мы реализуем витрину, а не Хранилище», — заявлял он всякий раз, когда произносилось слово «хранилище». С технической точки зрения, он был прав. Это была действительно витрина, причем с очень хорошей архитектурой. В конце концов, менеджер добился своего, и все стали использовать правильный термин, упоминая о витрине данных. Через год после завершения реализации, витрину перестали применять, так как она не давала реального результата.

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

Длительный процесс

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

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

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

Долговременная поддержка

После реализации Хранилища команда разработчиков, как правило, отстраняется от дальнейшей деятельности. Однако кто же будет поддерживать проект? Многие компании часто недооценивают важность обслуживания, которое необходимо для контроля ETL-процессов, поддержки производительности и обновлений, которые будут регулярно требоваться для управления Хранилищем. При оценке будущего проекта необходимо учитывать операционные расходы на Хранилище.

Гибким ли оказалось Хранилище? Насколько трудно добавлять новые источники данных, таблицы или поля после того, как проект запущен в работу? Эти вопросы необходимо проанализировать и проверить еще в процессе разработки.

Реальность — не идеология

Ну а как же теории и оптимальные методы вписываются в реальную ситуацию в компании? Многие фирмы, особенно небольшие и средние, отказываются от разработки Хранилища, так как им она кажется слишком дорогой. На самом деле это не так — дороги только некоторые раздутые архитектуры корпоративных Хранилищ. Если у компании нет средств на реализацию многомерной шины (dimensional bus) или Корпоративной информационной фабрики (Corporation Information Factory), нужно использовать только отдельные ключевые моменты этой методологии, удовлетворяющие потребностям организации.

На этапе анализа и дизайна использование оптимальных методов может быть важным, но еще существеннее оценка этих методов относительно ситуации в компании и ее потребностей. Один из клиентов автора работал с витриной данных, которая соответствовала всем принципам многомерного моделирования. Однако, для создания одного из главных отчетов, необходимого пользователям, потребовалось объединение двенадцати таблиц и создание временной таблицы с помощью хранимой процедуры. Несмотря на соответствие данной витрины всем принципам методики, она не удовлетворяла требованиям этого пользователя.

В данном случае, возможно, многомерная модель была выбрана правильно, а реализация — нет. Но, может быть, с учетом уникальных требований к отчетности, не нужно было использовать многомерный подход. Если так, то не стоит бояться изменять оптимальные методы, адаптируя их к реальным условиям в компании.