Илья Галахов , начальник управления методологии
программных систем компании «Сибинтек» (Москва).

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

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

 

 

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

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

Подходы к созданию информационно-аналитических систем

Традиционные подходы к построению информационно-аналитических систем исходят из того, что в начале проекта сложно сказать, что должно быть помещено в хранилище данных и какие аналитические задачи будут решаться конечными пользователями. Например, методология Oracle DWM FT (Datawarehouse Method Fast Track — метод создания хранилищ «высокоскоростная трасса») исходит из предположения, что разработчики на протяжении практически всего жизненного цикла информационно-аналитической системы будут заниматься определением и анализом требований к хранилищу данных. Основанная на DSDM (Dynamic System Development Method — метод разработки динамических систем) эта методология реализует подход RAD (Rapid Application Development — быстрая разработка приложений).

Согласно DSDM и Oracle DWM FT, цикл проектирования проходит через создание ряда прототипов до тех пор, пока не будут удовлетворены требования конечных пользователей. Чтобы этот цикл не стал бесконечным, разработка делится на 120-дневные временные отрезки (timebox), за которые реально выполнить определенный, не расширяющийся набор требований (по аналогии с ящиком для игрушек toybox, в который невозможно поместить дополнительные игрушки, не вытащив уже лежащие там). Утверждается, что благодаря гибкости и простоте использования инструментов Business Intelligence, прототипирование не составляет труда. Однако, такой подход оправдан для его применения ИТ-специалистами, которые стараются не слишком расширять свои познания в предметной области.

Метод RAD хорошо зарекомендовал себя при создании небольших приложений. Однако подобно тому как при создании сложных транзакционных систем уровня предприятия возникает потребность в реинжиниринге бизнес-процессов, так при создании корпоративных информационно-аналитических систем будет востребован бизнес-инжиниринг — создание организации, ориентированной на выполнение определенной стратегии. Хотя разработчики информационно-аналитических систем, будут продолжать итеративное проектирование по принципу «Чего изволите?», сегодня наиболее перспективным является выработка бизнес-ориентированного подхода, основанного на BSC (Balanced Scorecard — система сбалансированных показателей).

Подход BSC с самого начала определяет бизнес-аспекты анализируемых данных, что позволяет проектировать информационно-аналитическую систему сверху-вниз параллельно с внедрением на предприятии MBO (Management by objectives — управление, основанное на достижении целей). Вместо исключительно ретроспективных финансовых метрик, в хранилищах данных, созданных на основе подхода BSC, станут учитываться «опережающие индикаторы» (leading indicator), позволяющие прогнозировать изменения в бизнесе. Такие хранилища дадут аналитикам целостную картину развития предприятия, как минимум по четырем направлениям:

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

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

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

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

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

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

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

При выборе инструментов BSC важно знать, что существует добровольная программа их сертификации, проводимая компанией Balanced Scorecard Collaborative, организованная авторами методологии Balanced Scorecard. Сертификация осуществляется на основе функциональных стандартов (BSC Functional Standards). К данному моменту сертификацию прошли BSC-инструменты компаний Cognos, Crystal Decisions, Fiber FlexSI, Hyperion, InPhase, Oracle, Peoplesoft, Pilot Software, QPR, SAP, SAS и ряда других.

Следующий этап проектирования информационно-аналитической системы — определение «ключевых показателей эффективности» (KPI, Key Performance Indicator), численных характеристик выбранных целей (метрик, которые необходимо собирать в хранилище данных). По сути, эти метрики задают состав данных в хранилище.

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

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

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

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

Многомерное проектирование

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

Поскольку деятельность любого предприятия протекает во времени, первый вопрос, который возникает при анализе, это вопрос о динамике развития бизнеса. Правильная организация оси времени позволит качественно ответить на этот вопрос. Обычно ось времени делится на годы, кварталы и месяцы. Возможно еще большее дробление на недели и дни. Структура временного измерения формируется с учетом периодичности поступления данных; может обуславливаться также периодичностью востребования информации. Для временного измерения возможно создание специальных категорий, например, ‘текущий месяц' или ‘текущий день' когда для удобства интервал с начала месяца до текущего дня или аналогичный промежуток времени в истекшем году могут быть выделены в особые категории. Тогда ежедневные типовые отчеты пользователя, использующие подобные категории с переменными временными интервалами всегда будут содержать готовую к анализу информацию на текущий момент. В некоторых компаниях анализ во времени ведется относительно финансового года. В этом случае можно поступить двояко: либо изменить разбиение временного измерения так, чтобы началом года являлось, например, 1 апреля, либо ввести второе (альтернативное) деление оси времени специально для финансового анализа. В последнем случае анализ будет возможен как относительно календарного, так и финансового года. При этом дополнительную ось времени создавать не требуется.

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

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

Если же аналитика интересует сопоставление категорий заказчиков с их размером: объемом проданных товаров данной категории заказчиков, то не следует вводить альтернативную классификацию по размерам заказчиков. Анализ выиграет, если предоставить возможность пользователю вычленять из той или иной категории заказчиков крупных и мелких клиентов. Поэтому, хотя в обоих случаях речь идет о классификации одних и тех же объектов-заказчиков, необходимо организовать два измерения: «Заказчики по категориям» и «Заказчики по размерам». Разница между альтернативной классификацией и организацией дополнительного измерения состоит в том, что в первом случае одна и та же ось разбита различными способами, а во втором используются две различных оси. Имея несколько измерений для классификации одних и тех же объектов, становится возможным вычленение подмножеств не по одной, а по нескольким характеристикам: виду, категории, новизне и т.д.

Для анализа эффективности деятельности подразделений следует создать свое измерение. Например, можно выделить два уровня иерархии: департаменты и входящие в них отделы, что и должно найти отражение в измерении «Подразделения».

По сути, измерения «Время», «Товары», «Заказчики» достаточно полно определяют пространство предметной области. Дополнительно, полезно разбить это пространство на условные области, взяв за основу вычисляемые характеристики, например, диапазоны объема сделок в стоимостном выражении. Тогда весь бизнес можно разделить на ряд стоимостных диапазонов, в котором он осуществляется. В данном примере можно ограничиться следующими показателями: суммами продаж товаров, количеством проданных товаров, величиной дохода, количеством сделок, количеством клиентов, объемом закупок у производителей.

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

Выбор архитектуры OLAP-приложения

При реализации информационно-аналитической системы важно не ошибиться в выборе архитектуры OLAP-приложения. Дословный перевод термина On-Line Analytical Process — «оперативная аналитическая обработка» — часто воспринимается буквально в том смысле, что поступающие в систему данные оперативно анализируются. Это заблуждение — оперативность анализа никак не связана с реальным временем обновления данных в системе. Эта характеристика относится к времени реакции OLAP-системы на запросы пользователя. При этом зачастую анализируемые данные представляют собой снимок информации «на вчерашний день», если, например, данные в хранилищах обновляются раз в сутки.

В этом контексте более точен перевод OLAP как «интерактивная аналитическая обработка». Именно возможность анализа данных в интерактивном режиме отличает OLAP-системы от систем подготовки регламентированных отчетов.

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

Очевидно, что время формирования многомерной базы данных существенно зависит от объема загружаемых в нее данных, поэтому разумно ограничить этот объем. Но как при этом не сузить возможности анализа и не лишить пользователя доступа ко всей интересующей информации? Существует два альтернативных пути: Analyze then query («Сначала проанализируй — затем запроси дополнительную информацию») и Query then analyze («Сначала запроси данные — затем анализируй»).

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

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

В рассмотренном выше примере, пользователь не сможет сразу начать исследовать географию сбыта, если первоначальный микрокуб содержит детальные данные по измерениям «Время», «Подразделения» и «Товары» — придется подождать, когда будет сгенерирован новый микрокуб, содержащий дополнительные данные по измерению «Заказчики». Вспомним, что «оперативность» анализа гарантируется только в процессе работы с многомерной базой данных, однако время ее построения может быть сравнительно велико. Соответственно будет расти разочарование пользователя, вынужденного ожидать построения то одного, то другого микрокуба. Кроме того, постоянные обращения к реляционной базе данных могут снизить ее производительность. Подход Query then analyze реализует инструментальное средство BusinessObjects одноименной компании.

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

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

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

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

Наиболее яркими представителями подхода «Analyze then query» являются инструментальные средства PowerPlay и Impromptu компании Cognos.

Исходя из приведенных характеристик подходов к реализации OLAP, можно предположить, что инструментарий BusinessObjects более всего любим сотрудниками ИТ-служб, так как дает им возможность «откупиться» от назойливых пользователей путем простой установки и настройки этого инструментального средства. Конечные пользователи-непрограммисты скорее всего предпочли бы работать с готовой многомерной базой данных с помощью Cognos PowerPlay.

Cпроектировать готовую среду для многомерного анализа можно инструментами и от Cognos, и от BusinessObjects, которых аналитики Gartner и META Group относят к лидерам рынка OLAP. Интересные решения предлагают также компании Actuate, Arcplan, Brio, Computer Associates, Crystal, Hummingbird, Hyperion, Informatica, Information Builders, Microsoft, MicroStrategy, Oracle, Peoplesoft, ProClarity, SAP, SAS, Siebel и других (www.olapreport.com/Architectures.htm).

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

Заключение

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

Общая структура мер и измерений

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

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

***

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

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

Cпроектировать готовую среду для многомерного анализа можно инструментами и от Cognos, и от BusinessObjects, которых аналитики Gartner и META Group относят к лидерам рынка OLAP. Интересные решения предлагают также компании Actuate, Arcplan, Brio, Computer Associates, Crystal, Hummingbird, Hyperion, Informatica, Information Builders, Microsoft, MicroStrategy, Oracle, Peoplesoft, ProClarity, SAP, SAS, Siebel.

Опубликовано в журнале "Открытые системы", №04, 2003 год

Статья получена: Клерк.Ру

загрузка...