Текст книги "Панели индикаторов как инструмент управления. Ключевые показатели эффективности, мониторинг деятельности, оценка результатов"

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

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

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

Напротив, витрины данных обычно разрабатываются на основе модели типа «звезда», в которой реляционные данные располагаются так, чтобы их можно было легко и быстро запрашивать и загружать в модули онлайновой аналитической обработки (OLAP). В отличие от нормализованных моделей в схеме типа «звезда» вся фактическая информация (например, числа) помещается в центральной таблице, окруженной множеством параметрических таблиц (поэтому такая схема и называется «звездой»), например по клиентам, по географическим признакам, по каналам, по продуктам. Параметрические таблицы фильтруют фактические данные центральной таблицы в ответ на запрос пользователя, например: «я хочу просмотреть доходы (то есть факты) за последние 12 месяцев (параметр «время») на Среднем Западе (параметр «география») по 10 нашим лучшим клиентам (параметр «оценка клиентов»).

Сегодня для удовлетворения информационных потребностей пользователей в большинстве компаний используется архитектура типа «звезда» (часто называемая в англоязычной литературе hub-and-spoke). Она предусматривает наличие центрального хранилища данных, которое питает информацией множество витрин данных на более низких уровнях. В такой среде пользователи обращаются с запросами к витринам данных, рассчитанных на информационные запросы конкретных отделов или рабочих групп. С запросами к хранилищу данных, которое содержит весь супернабор информации[1]1
  Исходная детальная информация, на основе которой рассчитываются витрины данных. – Прим. Ланит.


[Закрыть] для витрин данных, при этом обращаются лишь самые опытные бизнес-аналитики.

Использование витрин данных позволяет направить усилия технических специалистов на проектирование хранилищ данных, способных справляться с двумя главными задачами: 1) собирать и интегрировать данные от множества разных систем с максимально возможным дроблением и 2) готовить и распределять данные для витрин данных. Информация в хранилище данных никогда не уничтожается, так что оно служит центром их «бесконечного» обновления и областью подготовки. Такая многослойная архитектура позволяет техническим командам быстро создавать новые витрины данных за счет повторного их использования прямо в хранилище и, возможно, извлечения новых данных из оперативных систем или периодически (в серийном производстве), или в реальном времени с помощью инструментов интеграции корпоративных данных (EII). Однако не все специалисты по хранению данных считают такую многослойную архитектуру наилучшей (см. «Крупный план» 3.1).

Крупный план 3.1

АРХИТЕКТУРЫ ДЛЯ ХРАНЕНИЯ ДАННЫХ: БИТВА ТИТАНОВ

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

Модель Инмона. Эта модель, названная так в честь Билла Инмона, плодовитого автора и уважаемой фигуры в кругах «хранителей данных», построена на базе «звездной» архитектуры, в которой центральное хранилище данных служит подготовительной (staging) зоной для сбора данных от множества систем-источников с последующим распределением подмножеств этих данных по витринам данных более низкого уровня. В такой многослойной архитектуре пользователи обращаются с запросами не к хранилищам данных, а к витринам данных; хранилища данных при этом функционируют больше как зоны подготовки и центры распределения данных. Хранилища данных содержат подробные данные, тогда как витрины данных содержат главным образом обобщенные данные.

Модель Кимбола. Еще одно крупное направление поддерживает взгляды Ральфа Кимбола, тоже плодовитого автора и тоже уважаемой в отрасли фигуры. Модель Кимбола исключает потребность в хранилище данных. Обычно пользователям нужны детальные данные, и, по мнению Кимбола, их лучше хранить в индивидуальных витринах данных и логически объединять с использованием «соответствующих» параметров. В сущности, хранилище данных у Кимбола – это совокупность всех витрин данных. Чтобы обеспечить большую эффективность запросов и облегчить пользование витринами данных, Кимбол ввел другой тип модели данных, называемый схемой «звезда», которая сегодня широко используется, даже среди «инмонитов», при создании витрин данных.

Централизованная модель хранилища данных. Компания Teradata (отделение NCR) – сторонник использования хранилищ данных без каких бы то ни было витрин данных. Такой централизованный подход обеспечивает пользователям свободный доступ ко всем данным в хранилище данных, не ограничивая их отдельными витринами данных. Это также облегчает управление и обслуживание, потому что все данные хранятся централизованно, в пределах единой платформы управления данными. Однако централизованное хранилище данных может стать чрезвычайно большим и по объему хранимых данных, и по числу поддерживаемых пользователей. Чтобы обеспечить адекватное обслуживание запросов в больших централизованных хранилищах, организация должна иметь быстродействующую базу данных с параллельной обработкой (наподобие тех, которые поставляет Teradata).

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

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

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

Многие организации, еще больше запутывая ситуацию, создают специализированные хранилища данных, которые называются операционными складами данных (Operational Data Store, ODS), для поддержки операционных приложений, требующих быстрого доступа к интегрированным данным. В отличие от традиционных хранилищ данных и витрин данных, которые содержат огромные массивы статистических данных и поддерживают сложные запросы, требующие длительной обработки, операционные склады данных хранят данные лишь несколько месяцев и поддерживают быстро исполнимые поисковые запросы (например, относительно записей о клиентах). Кроме того, пользователи могут обновлять записи в операционных складах данных (но не в хранилищах данных, в которых новая запись обычно добавляется в конец существующей записи, но никогда ничего не стирается, чтобы обеспечить сохранность подлинных исторических записей о событиях).

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

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

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

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

Для поддержки режима обновления по мере необходимости («в нужное время») или даже в режиме реального времени группа управления эффективностью может также развернуть быстродействующее промежуточное программное обеспечение в сочетании с инструментами для выборки, трансформации и загрузки данных (ETL). Например, организации, использующие системы интеграции корпоративных приложений (EAI) для интегрирования пакетных и унаследованных приложений, теперь вводят данные в механизмы выборки, трансформации и загрузки данных в режиме реального времени. Такая «капельная» подача данных заменяет традиционные процессы пакетной загрузки, которые фактически позволяют хранить в хранилищах данных лишь прошлые статистические данные. Сочетание систем интеграции корпоративных приложений (EAI) и выборки, трансформации и загрузки данных (ETL) открывает перспективы преобразования хранилищ данных из громоздких исторических архивов в активные репозитории, представляющие информацию по запросам.

Еще одну возможность представления информации в нужное время открывает использование промежуточного программного обеспечения для интеграции корпоративной информации (EII). Эти инструменты могут обращаться с запросами ко многим, в том числе и распределенным, источникам данных, мгновенно объединять полученные результаты и представлять их конечным пользователям. Инструменты для интеграции корпоративной информации (EII) фактически генерируют динамическое виртуальное хранилище данных или динамическую виртуальную панель индикаторов в прозрачном для пользователя режиме. Однако многие инструменты для интеграции корпоративной информации хорошо работают только с небольшими объемами чистых и относительно энергонезависимых (non-volatile) данных, которые имеют четкие ключи к базе данных. Большинство экспертов согласно в том, что инструменты для интеграции корпоративной информации (EII) обеспечивают хорошую возможность создания прототипного контента проектируемого хранилища данных или панели индикаторов или дополнения существующего хранилища системой представления данных в нужное время или внешних данных.

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

Крупный план 3.2

ДЕЙСТВИТЕЛЬНО ЛИ НАМ НУЖНА ИНФРАСТРУКТУРА БИЗНЕС-АНАЛИЗА?

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

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

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

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

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

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

Инструменты для генерирования сообщений позволяют опытным пользователям и разработчикам генерировать заказные запросы и представлять полученные результаты в стандартном формате типовых сообщений, таких как детализированные отчеты или счета и банковские выписки установленной формы. Десять – двадцать лет назад большинство стандартных бизнес-сообщений писалось вручную на одном из языков программирования, печаталось на бумаге и рассылалось по почте, со скоростью улитки. Но теперь продавцы предлагают новые мощные инструменты для генерирования сообщений, реализуемые на самых разных платформах (в частности, это Windows, WebСети и большие универсальные компьютеры) и способные воспринимать данные от многих систем-источников. Инструменты теперь генерируют онлайновые сообщения, с которыми пользователи могут взаимодействовать, задавая связи с субсообщениями («связанные сообщения») или выбирая нужные параметры в раскрывающихся окнах списков («параметризованные сообщения»). Многие инструменты для генерирования сообщений работают теперь по принципу настольной издательской системы и позволяют разработчикам сообщений и опытным пользователям легко и быстро создавать заказные сообщения.

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

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