3. ИНСТРУМЕНТЫ

Процесс выбора исходного набора инструментов может оказаться долгим и непростым. Ведь нужно постараться сделать так, чтобы выбранный инструментарий обеспечивал удовлетворе ние и первоочередных насущных потребностей, и нефункциональных спецификаций, и даже еще не сформулированных требований в отношении решений следующего поколения. Уско рить выбор помогают готовые наборы критериев принятия решений и инструментов внедрения процессов, а также привлечение профильных специалистов. Важно учитывать и сравнивать по позициям не только традиционные опции построить самим vs купить готовое, но и предложе ния категории ПО как услуга (SaaS). Помимо собственно программных средств, концепция SaaS предлагает еще и практический опыт интеграции решений в среду организации, и сбалансиро ванное соотношение затрат/отдачи по сравнению со стоимостью постройки с нуля собственно го или издержками интеграции разнообразного покупного ПО. Приплюсуйте сюда еще и затра ты на регулярные обновления и (потенциально) замену неподходящих продуктов другими. Вы страивание же отношений с разработчиками на основе соглашений об уровнях обслуживания (SLA) или уровнях операционной поддержки (OLA) служит мостом к предсказуемости затрат и позволяет обеспечить себя всеми необходимыми функциями за привлекательно невысокую абонентскую плату и перекладывать издержки, проистекающие от сбоев в работе систем и/или приложений, на поставщика SaaS либо компенсировать их причитающимися с него пенями или неустойками.

3.1 Репозиторий метаданных

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

3.1.1 Словари и/или глоссарии данных

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

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

3.1.2 Происхождение данных и модели данных

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

расследование первопричин недостоверности, неточности и иных проблем с качеством данных;

анализ последствий системных изменений или проблем с данными;

составление рейтингов источников по показателям надежности и качества данных.

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

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

3.2 Средства интеграции данных

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

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

выборочное извлечение в заданное время конфигурируемой выборки данных из хранилища с передачей ее в систему аудита или контроля качества данных;

контроль произведенных и неудавшихся операций с последующим перезапуском сбойного или отмененного процесса (см. главу 8).

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

3.3 Типы инструментов BI

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

Операционная отчетность позволяет выявлять и анализировать краткосрочные (помесяч ные) и среднесрочные (годовые) тенденции и закономерности. Используйте тактический биз нес-анализ (Tactical BI) для выработки и принятия краткосрочных решений в сфере оператив ного управления бизнесом.

1 Материал настоящего раздела по большей части позаимствован из книги: Cindi Howson, «The Business Intelligence Market: Secrets to Making BI a Killer App», McGraw-Hill, 2008, — с разрешения правообладателя и с некоторыми измене ниями и дополнениями.

2 Портал Dataversity описывает эту тенденцию понятием «демократизация технологий работы с данными». Подробнее см.: Ghosh, Paramita. «A Comparative Study of Business Intelligence and Analytics Market Trends». Dataversity. January 17, 2017 (http://bit.ly/2sTgXTJ, ссылка проверена 30.05.19).

Управление эффективностью бизнеса позволяет производить формальную оценку изме римых показателей, соответствующих целям организации. Осуществляется, как правило, на уровне высшего руководства. Используйте стратегический бизнес-анализ (Strategic BI) для формулировки долгосрочных целей и задач.

Описательная (descriptive) аналитика, аналитика самообслуживания (self-service) обеспечи вают прикладной анализ текущих вопросов. Сочетание BI-приложений с функциями и про цессами операционного управления позволяет задействовать анализ данных в принятии ре шений в режиме, близком к реальному времени. Требование минимизации времени задержки регистрации и доставки данных (максимальной приближенности к режиму реального време ни) диктует выбор архитектуры решений. Для полноценной операционной аналитики сегодня требуются сервис-ориентированная архитектура (SOA) и большие данные (см. главы 8 и 15).

3.3.1 Операционная отчетность

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

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

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

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

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

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

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

3.3.2 Управление эффективностью бизнеса

Управление эффективностью бизнеса (Business Performance Management, BPM) — это набор ин тегрированных процессов организации и приложений, разработанных для оптимизации испол нения бизнес-стратегии. Стандартный набор поддерживает формирование бюджета, планирова ние, бухгалтерский учет и сводную финансовую отчетность. Наработки в этом сегменте имеются огромные, поскольку производители программного обеспечения как для управления предприя тием (ERP), так и для BI видят в данной области огромные резервы роста, к тому же грань между бизнес-аналитикой и управлением эффективностью всё более стирается. Частота приобретения клиентами решений в области BI и управления эффективностью от одного и того же разработчи ка зависит от возможностей поставляемых им продуктов.

Не вдаваясь в подробности, отметим лишь, что технология BPM позволяет приводить процес сы в соответствие с организационными целями. Ключевые элементы BPM — измерения и петля положительной обратной связи. В сфере BI это приняло форму множества приложений для раз личных стратегических областей деятельности предприятия — бюджетного планирования, про гнозирования, планирования ресурсов и т. п. Другая специализация BI сформировалась строго внутри этой области и включает создание карт балльной оценки в связке с приборными панеля ми для интерактивного информирования пользователей. Как и в автомобиле, на приборную па нель, находящуюся в поле зрения конечного пользователя, выводится сводка текущих значений важнейших показателей (Eckerson, 2005).

3.3.3 Приложения для оперативного анализа

Термин аналитические приложения (analytic applications) ввел в 1990-х годах Генри Моррис из International Data Corporation (IDC), тем самым подчеркивая их отличия от технологий онлай новой аналитической обработки (OLAP1) и бизнес-аналитики (Morris, 1999). Аналитические

1 сокр. от англ. Online Analytical Processing. — Примеч. пер.

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

3.3.3.1 МНОГОМЕРНЫЙ АНАЛИЗ — OLAP

Термин онлайновая аналитическая обработка данных (OLAP) используется для описания под хода, обеспечивающего высокопроизводительную обработку многомерных аналитических за просов. Термин OLAP возник отчасти в противовес термину OLTP1, использующемуся для обо значения онлайновой обработки транзакций. Обычно выдача данных в ответ на запросы OLAP происходит в матричном формате. Измерения определяются столбцами и строками матрицы, на пересечении которых выводятся факторы или значения. Концептуально это представление ил люстрируется как куб данных. Многомерный анализ с кубами особенно полезен там, где у ана литиков имеется хорошее представление об общей картине и структуре данных, а разобраться хочется с динамикой и сводной статистикой.

Традиционная область применения OLAP — финансовый анализ, ведь специалисты в этой области привыкли сновать вверх-вниз и туда-сюда по сводным таблицам данных, упорядо ченных в рамках хорошо известных иерархий, выискивая и анализируя тенденции и законо мерности; а кубы данных позволяют с легкостью переходить на иную шкалу измерений или масштабов даты/времени (годичные, квартальные, месячные, недельные, суточные, почасо вые показатели и т. д.), организационной структуры (мир, регион, страна, отрасль, компания, подразделение и т. д.), иерархии продуктов (категория, линия, наименование продукта) и т. п. Многие пакеты программного обеспечения для BI сегодня используют OLAP-кубы в качестве одной из базовых моделей, а некоторые еще и поддерживают автоматизацию и бесшовную ин теграцию процессов определения и заполнения кубов данных. А это означает, что любой поль зователь может играться в такие «кубики», нарезая данные вдоль и поперек, как душе угодно. Поэтому постарайтесь открывать доступ к подобным функционалам лишь привилегирован ным категориям продвинутых пользователей из числа специалистов в своих предметных об ластях заодно с выделенным каналом самообслуживания, чтобы лишь немногие избранные имели возможность и свободу анализировать данные по своему усмотрению, но с пользой для организации.

Обычно прикладные OLAP-системы имеют серверный компонент и клиентское приложение для персонального компьютера или веб-интерфейс. Некоторые компоненты, устанавливаемые

1 сокр. от англ. Online Transaction Processing. — Примеч. пер.

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

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

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

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

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

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