hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

2.4 Заполнение хранилища данных

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

Самая трудоемкая часть работы по созданию DW/BI — подготовка к приему, обработке и сохра нению данных, поступающих из различных источников, в рабочем режиме. Архитектура и мо дель данных определяют детальное содержание DW и являются ключевым приоритетом при проектировании системной архитектуры DW/BI. Публикация четких правил, расписывающих, какие данные будут доступны только через каналы учета текущих операций (то есть не будут отправляться в DW), — важнейшее условие успеха всего проекта создания DW/BI.

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

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

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

2.5 Внедрение портфеля инструментов BI

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

Ведение хранилищ данных и бизнес-аналитика

493

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

2.5.1 Распределение пользователей по группам в соответствии с потребностями

Целевые группы пользователей должны определяться на основе изучения спектра их потребно стей в BI-средствах. Прежде всего выделите основные группы пользователей и изучите их состав,

азатем определите применительно к каждому инструменту BI, какие группы в нем нуждаются,

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

Следует предусмотреть возможность перевода пользователей из одной группы или катего рии в другую: например, при повышении уровня профессионализма, переходе в другое функцио нальное подразделение и т. п. Уровни доступов к данным различных категорий в каждой группе должны быть дифференцированными. Например, снабженцам достаточно статичных сводных финансовых отчетов, но требуются максимально детализированные интерактивные представле ния данных из системы учета складских запасов с максимальной аналитической оснасткой. И, на против, финансовым аналитикам и бухгалтерам производственных подразделений должен быть разрешен полноправный динамический доступ к детализациям приходно-расходных статей, но вполне достаточно статичной сводки наличных материальных ресурсов. Руководителям высшего и среднего звена потребуется сочетание фиксированного набора отчетов в установленной форме, приборных панелей и оценочных карт. Менеджеры и продвинутые пользователи имеют склон ность вгрызаться в профильные отчеты и раскладывать данные из них по косточкам, доиски ваясь до корневых причин имеющихся проблем. Внешним потребителям могут потребоваться любые из вышеописанных средств BI, поскольку среди них присутствуют лица с самыми разно образными интересами и опытом.

2.5.2 Обеспечение соответствия инструментария потребностям пользователей

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

494	Г Л А В А 11

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

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

2.6 Сопровождение информационных продуктов

Внедренное DW и его ориентированная на потребителей данных часть, включающая клиентские приложения и инструменты BI, превращаются, по сути, в информационный продукт. Последую щие усовершенствования платформы DW (дополнения, надстройки и/или модификации) следу ет внедрять поэтапно, методом приращений.

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

2.6.1 Управление релизами

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

Ведение хранилищ данных и бизнес-аналитика

495

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

а требует участия также и бизнес-подразделений, и проектировщиков модели данных, и бизнесаналитиков. Это комплекс совместных действий по непрерывному улучшению.

Рисунок 83 содержит иллюстративный пример организации процесса управления выпуском релизов по ежеквартальному плану-графику. За год выпускаются три релиза для бизнес-нужд и еще один — для технологических (служебный релиз для обслуживания хранилища данных). Процесс должен предусматривать поэтапное развитие DW/BI и ведение хронологического архи ва выполненных технических и бизнес-требований.

Релиз +1

Релиз +2

Релиз +3

• Три квартальных релиза

Поэтапная поставка

Поэтапная поставка

Поэтапная поставка

для бизнес-единиц, обеспечивающие

Квартальный

Квартальный

Квартальный

поэтапное наращивание возможностей

«Заморозка» требований

«Заморозка» требований

«Заморозка» требований

• Состав работ определяется согласно списку

Приоритизация работ

Приоритизация работ

Приоритизация работ

приоритетов MuSCoW

(MuSCoW)

(MuSCoW)

(MuSCoW)

• Сроки работ задаются жестко

Обязательно (Must)

Нужно (Should)

Желательно (Could)

Четвертый релиз –

для внутреннего

BICC

использования

Сокращение

Пересмотр

Внутренний релиз 0

Приоритетная работа?

Нет (Won’t)

объемов работ

Квартальный

0.1

Собранные результаты

0.2

Уточнение оценок

0.3

Извлечение уроков

0.4

Управление знаниями

0.5

Обновление программного

и технического обеспечения

BICC

0.6

Обучение/подготовка

0.7

Временные решения

Определение

Смягчение

приоритетов

ситуации

реализации

Временные

решения

Публикация

BICC

Дефект

Ограничения

(временные

решения)

План выпуска релизов +4, 5, 6

(на основе результатов эксплуатации, новых

Известные

сведений и списка приоритетов релизов 1, 2, 3)

Смягчение

Обновления в связи с учетом:

дефекты

ситуации

0.1 Совершенствования методов

0.2 Результатов калькуляции трудозатрат

0.3 Лучших практик

0.4 Уровня информированности

0.5 Перспектив развития возможностей программного и технического обеспечения

0.6 Сертификации ресурсов

0.7 Необходимости согласования с тактическими и стратегическими целями

BICC = Центр компетенций BI (BI Competence Center)

Рисунок 83. Пример процесса управления релизами

496	Г Л А В А 11

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

2.6.2 Управление жизненным циклом разработки информационного продукта

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

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

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

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

Лишь новинки, успешно прошедшие испытания и утвержденные к внедрению руководством как ИТ-, так и бизнес-подразделения, могут внедряться в среде DW/BI в качестве новых инфор- мационно-аналитических продуктов. После внедрения итерация считается завершенной.

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

2.6.3 Мониторинг и оптимизация нагрузки

Рабочая нагрузка должна контролироваться на уровне всех реализованных в системе процес сов, что позволяет отслеживать причины задержек обработки и прохождения данных вверх по

Ведение хранилищ данных и бизнес-аналитика

497

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

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

Пользователи часто считают DW чем-то вроде архива в активном доступе из-за наличия там длительных историй накопления данных, и знать не желают, что DW само по себе нужда ется в архивировании и ведении резервных копий, — а потом удивляются пропаже записей, в особенности из интерактивных источников аналитических данных (OLAP) (см. главу 6).

2.6.4 Мониторинг использования и настройка производительности средств BI

Оптимальной считается практика мониторинга и выявления потребностей в настройке BI-систем

иприложений посредством определения и отображения текущих показателей удовлетворенно сти потребителей. Примеры других полезных показателей — среднее время отклика на запрос, число пользователей и/или запросов в сутки, неделю или месяц. Помимо статистических метрик, получаемых непосредственно из систем, полезно проводить и регулярные опросы или анкетиро вания пользователей комплекса DW/BI.

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

Прозрачность и наглядность — ключевые принципы мониторинга DW/BI. Чем больше дета лей о работе комплекса DW/BI отображается, тем проще потребителям понять, откуда берутся

икак анализируются данные, — что повышает доверие к BI и снижает число обращений в службу поддержки за разъяснениями.

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

ипользователей.

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

498	Г Л А В А 11